[N8VEM: 16243] Hard disk image for the N8VEM

[oscarv]

Hi,

Somehow I never quite got around to loading up a N8VEM hard disk image with
all the classic CP/M software, and I'd expect that goes for more people.

But then I had to prepare something nice to showcase the N8VEM at the VCFe
last weekend. So I finally spent a few (more than a few, in the end) hours
filling a disk image. If you want, you can download this image here<https://docs.google.com/file/d/0B_jM3_1AFMbMVS1RaXZ5eVBQNnc/edit?usp=sharing>,
and a small booklet with descriptions here<https://docs.google.com/file/d/0B_jM3_1AFMbMYUcyUUNLdjlyb28/edit?usp=sharing>.
As it is for RomWBW, it'll work on SDs and CFs, on the N8VEM and the Zeta.
It's certainly neither perfect nor complete, but it holds all the big
languages and applications so it's a start.

BTW, the VCFe exhibit itself is described here<http://obsolescenceguaranteed.blogspot.ch/2013/10/n8vem-vcfe-141-winterthur-switzerland.html>
.

Cheers,

Oscar.

[Douglas Goodall]

Oscar,

I tried to download thee zip file but don’t seem to have the right permissions.

Help please.

Douglas Goodall

Hi,
Somehow I never quite got around to loading up a N8VEM hard disk image with all the classic CP/M software, and I'd expect that goes for more people.
But then I had to prepare something nice to showcase the N8VEM at the VCFe last weekend. So I finally spent a few (more than a few, in the end) hours filling a disk image. If you want, you can download this image here, and a small booklet with descriptions here. As it is for RomWBW, it'll work on SDs and CFs, on the N8VEM and the Zeta. It's certainly neither perfect nor complete, but it holds all the big languages and applications so it's a start.
BTW, the VCFe exhibit itself is described here.
Cheers,
Oscar.
--
You received this message because you are subscribed to the Google Groups "N8VEM" group.
Visit this group at http://groups.google.com/group/n8vem.
For more options, visit https://groups.google.com/groups/opt_out.

[oscarv]

Douglas,

Post by Douglas Goodall

Post by Douglas Goodall
I tried to download thee zip file but don’t seem to have the right

permissions.

How bizarre... a friend just checked, it worked for him. Click the link,
then on the Google drive page press CTRL-S or download from the menu.

But if it does not work on your browser, can I email you a 9MB file?

Regards,

Oscar.

[Douglas Goodall]

Hi Oscar,

I believe I just downloaded the dat file ok.

The default device size for SD and CF is 64MB.

7 = 64 / 9

That gives us seven logical units on a 64MB chip.

So beyond the four logical drives that are mapped by default
to LU0,LU1,LU2,LU3, the MAP command can access all seven
of the logical units.

I would use multifmt to prepare a 64MB chip, then load away.

This way you can use all of the 64MB chip, and not just the first 32MB (actually the first 36MB).

Hi,
Somehow I never quite got around to loading up a N8VEM hard disk image with all the classic CP/M software, and I'd expect that goes for more people.
But then I had to prepare something nice to showcase the N8VEM at the VCFe last weekend. So I finally spent a few (more than a few, in the end) hours filling a disk image. If you want, you can download this image here, and a small booklet with descriptions here. As it is for RomWBW, it'll work on SDs and CFs, on the N8VEM and the Zeta. It's certainly neither perfect nor complete, but it holds all the big languages and applications so it's a start.
BTW, the VCFe exhibit itself is described here.
Cheers,
Oscar.
--
You received this message because you are subscribed to the Google Groups "N8VEM" group.
Visit this group at http://groups.google.com/group/n8vem.
For more options, visit https://groups.google.com/groups/opt_out.

---
Douglas Goodall
doug-***@public.gmane.org
http://goodall.us.com
WQRLl515

[oscarv]

Douglas,


On Tuesday, October 8, 2013 2:24:52 PM UTC+2, douglas_goodall wrote:

[...] the MAP command can access all seven of the logical units.

Post by Douglas Goodall
I would use multifmt to prepare a 64MB chip, then load away.

Yes, I already did so but wanted to concentrate as much as possible on the
first 4 LU's. There's already some stuff on LU5 by now, the main problem
not being the storage capacity per drive but the max number of files on
each of them.

I'll put the disk image, plus cpmtools batch files etc on my website this
weekend and post a referral link on the N8VEM website.

In the mean time, if anyone has a suggestion for adding other software, let
me know. I have the good intention to grow & maintain this disk image over
time (but then, good intentions suffer from reality over time of course).

Regards,

Oscar.

[Douglas Goodall]

Oscar,

I approve of your intentions and will be helpful in any way I can.

It was my intention to standardize on a 2GB chip (image) and use about
220 LU's to store all available CP/M programs, and to both post the image
on the Internet, but also sell them at cost plus postage to those who might
need to just plug it in.

Douglas

Post by oscarv
Douglas,
[...] the MAP command can access all seven of the logical units.
I would use multifmt to prepare a 64MB chip, then load away.
Yes, I already did so but wanted to concentrate as much as possible on the first 4 LU's. There's already some stuff on LU5 by now, the main problem not being the storage capacity per drive but the max number of files on each of them.
I'll put the disk image, plus cpmtools batch files etc on my website this weekend and post a referral link on the N8VEM website.
In the mean time, if anyone has a suggestion for adding other software, let me know. I have the good intention to grow & maintain this disk image over time (but then, good intentions suffer from reality over time of course).
Regards,
Oscar.
--
You received this message because you are subscribed to the Google Groups "N8VEM" group.
Visit this group at http://groups.google.com/group/n8vem.
For more options, visit https://groups.google.com/groups/opt_out.

---
Douglas Goodall
doug-***@public.gmane.org
http://goodall.us.com
WQRLl515

[oscarv]

Douglas,

Post by Douglas Goodall
It was my intention to standardize on a 2GB chip (image) and use about
220 LU's to store all available CP/M programs

2GB of CP/M, that would be nice! A lot more ambitious than my 32MB 'Best
Of' attempt.

I found Google Drive a slightly cumbersome but trustworthy *and free*solution. Any chance of posting yours? Happy to help.

In the mean time, I put my 32MB disk image on this page for anyone who
cares. I forgot to say, it also comes with all the PDF manuals. And I put a
zip file with the tools I used for the sake of convenience.

The page is here: <32MB N8VEM Demo Hard Disk Image and support materials><http://obsolescence.wix.com/obsolescence#!n8vemimage/c1v04>

Regards,

Oscar.

[Douglas Goodall]

Oscar,

Lets work on it together. I would be happy to post the results on my servers.

I have a colocated server and also a cloud server. Between the two, they are very reliable.

I am about to bring my N8-2312 back up and I can use that to master the new chip image.

I would be happy to make you an account on my server so you can upload bits.

Is this a good approach?

Douglas

Post by oscarv
Douglas,
It was my intention to standardize on a 2GB chip (image) and use about
220 LU's to store all available CP/M programs
2GB of CP/M, that would be nice! A lot more ambitious than my 32MB 'Best Of' attempt.
I found Google Drive a slightly cumbersome but trustworthy and free solution. Any chance of posting yours? Happy to help.
In the mean time, I put my 32MB disk image on this page for anyone who cares. I forgot to say, it also comes with all the PDF manuals. And I put a zip file with the tools I used for the sake of convenience.
The page is here: <32MB N8VEM Demo Hard Disk Image and support materials>
Regards,
Oscar.
--
You received this message because you are subscribed to the Google Groups "N8VEM" group.
Visit this group at http://groups.google.com/group/n8vem.
For more options, visit https://groups.google.com/groups/opt_out.

---
Douglas Goodall
doug-***@public.gmane.org
http://goodall.us.com
WQRLl515

[oscarv]

Douglas,

Post by Douglas Goodall
Lets work on it together.

Yes, by all means!

Post by Douglas Goodall
I would be happy to post the results on my servers.

So what I've got is on that web page<http://obsolescence.wix.com/obsolescence#!n8vemimage/c1v04>for now: the disk image, the little booklet, a zip file with all the
software manuals and 'what passes for the tools' I used. Feel free to store
them wherever it makes sense.

Post by Douglas Goodall
I would be happy to make you an account on my server so you can upload bits.

OK - I'll send you an email tonight to get things going.

Post by Douglas Goodall
Is this a good approach?

I think so. The N8VEM is a lot more fun with a pret-a-porter disk image,
and if we can make it a Humongous one, all the better.

Although I'd like to keep a small "Best Of" image file as well (a 64MB
image is easier to handle and fits on whatever old CF card people use).

Regards,

Oscar.

[Bob Devries]

Hi Douglas,

I'm having a problem using the hard disk image with my ZETA, using PPIDE. I copied the .DAT file to a 1GiB CF card, and I can access it, but I don't see all the logical units as named in the document.

I tried MULTIFMT, but it doesn't erase the CF card.

I'm using v 2.5.1 of ROMWBW; not quite the latest, but I thought it should work. Is there any special magic words I need to use? ;)

I use a PC programme called DISKIMAGE to copy the .DAT filr to the CF card. Should I format the card first?

Regards, Bob Devries
Dalby, QLD, Australia

----- Original Message -----
From: Douglas Goodall
To: n8vem-/***@public.gmane.org
Sent: Tuesday, October 08, 2013 10:24 PM
Subject: Re: [N8VEM: 16245] Hard disk image for the N8VEM


Hi Oscar,


I believe I just downloaded the dat file ok.


The default device size for SD and CF is 64MB.


7 = 64 / 9


That gives us seven logical units on a 64MB chip.


So beyond the four logical drives that are mapped by default
to LU0,LU1,LU2,LU3, the MAP command can access all seven
of the logical units.


I would use multifmt to prepare a 64MB chip, then load away.


This way you can use all of the 64MB chip, and not just the first 32MB (actually the first 36MB).




On Oct 7, 2013, at 2:56 PM, oscarv <vermeulen.oscar-***@public.gmane.org> wrote:


Hi,

Somehow I never quite got around to loading up a N8VEM hard disk image with all the classic CP/M software, and I'd expect that goes for more people.

But then I had to prepare something nice to showcase the N8VEM at the VCFe last weekend. So I finally spent a few (more than a few, in the end) hours filling a disk image. If you want, you can download this image here, and a small booklet with descriptions here. As it is for RomWBW, it'll work on SDs and CFs, on the N8VEM and the Zeta. It's certainly neither perfect nor complete, but it holds all the big languages and applications so it's a start.

BTW, the VCFe exhibit itself is described here.

Cheers,

Oscar.








--
You received this message because you are subscribed to the Google Groups "N8VEM" group.
To unsubscribe from this group and stop receiving emails from it, send an email to n8vem+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To post to this group, send email to n8vem-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
Visit this group at http://groups.google.com/group/n8vem.
For more options, visit https://groups.google.com/groups/opt_out.



---
Douglas Goodall
doug-***@public.gmane.org
http://goodall.us.com
WQRLl515



--
You received this message because you are subscribed to the Google Groups "N8VEM" group.
To unsubscribe from this group and stop receiving emails from it, send an email to n8vem+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To post to this group, send email to n8vem-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
Visit this group at http://groups.google.com/group/n8vem.
For more options, visit https://groups.google.com/groups/opt_out.

[Douglas Goodall]

Bob,

A little background…

When you are starting with a chip whose contents are unknown, you want to prepare
the chip in two respects. First there is the preparation of the directory entries which
get filled with E5's, and secondly there is a sector of metadata which includes a label
and some other stuff.

Multifmt does both, leaving you with a set of empty directories and default metadata.

After this you can copy files onto the various logical units and user numbers.

During the preparation of the .DAT file, this should have been done,

If you are using a .dat file, you should not need to format the chip in any way as all
that will be overwritten.

I don't know if the current .dat file was prepared in this way. If not the metadata might
not be there.

When you say you are not seeing the logical units you expect, are those logical units
you are looking for or user numbers?

Regards,
Douglas

Post by Bob Devries
Hi Douglas,
I'm having a problem using the hard disk image with my ZETA, using PPIDE. I copied the .DAT file to a 1GiB CF card, and I can access it, but I don't see all the logical units as named in the document.
I tried MULTIFMT, but it doesn't erase the CF card.
I'm using v 2.5.1 of ROMWBW; not quite the latest, but I thought it should work. Is there any special magic words I need to use? ;)
I use a PC programme called DISKIMAGE to copy the .DAT filr to the CF card. Should I format the card first?
Regards, Bob Devries
Dalby, QLD, Australia
----- Original Message -----
From: Douglas Goodall
Sent: Tuesday, October 08, 2013 10:24 PM
Subject: Re: [N8VEM: 16245] Hard disk image for the N8VEM
Hi Oscar,
I believe I just downloaded the dat file ok.
The default device size for SD and CF is 64MB.
7 = 64 / 9
That gives us seven logical units on a 64MB chip.
So beyond the four logical drives that are mapped by default
to LU0,LU1,LU2,LU3, the MAP command can access all seven
of the logical units.
I would use multifmt to prepare a 64MB chip, then load away.
This way you can use all of the 64MB chip, and not just the first 32MB (actually the first 36MB).

Hi,
Somehow I never quite got around to loading up a N8VEM hard disk image with all the classic CP/M software, and I'd expect that goes for more people.
But then I had to prepare something nice to showcase the N8VEM at the VCFe last weekend. So I finally spent a few (more than a few, in the end) hours filling a disk image. If you want, you can download this image here, and a small booklet with descriptions here. As it is for RomWBW, it'll work on SDs and CFs, on the N8VEM and the Zeta. It's certainly neither perfect nor complete, but it holds all the big languages and applications so it's a start.
BTW, the VCFe exhibit itself is described here.
Cheers,
Oscar.
--
You received this message because you are subscribed to the Google Groups "N8VEM" group.
Visit this group at http://groups.google.com/group/n8vem.
For more options, visit https://groups.google.com/groups/opt_out.

---
Douglas Goodall
http://goodall.us.com
WQRLl515
--
You received this message because you are subscribed to the Google Groups "N8VEM" group.
Visit this group at http://groups.google.com/group/n8vem.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups "N8VEM" group.
Visit this group at http://groups.google.com/group/n8vem.
For more options, visit https://groups.google.com/groups/opt_out.

---
Douglas Goodall
doug-***@public.gmane.org
http://goodall.us.com
WQRLl515

[Bob Devries]

Hi Douglas,

Well, I formatted the CF card in Windows, and then plugged it into my ZETA.

I then used MULTIFMT to format it for CP/M.
After that was done, the output of MAP is:
[QUOTE]
MAP.COM 6/25/2013 v2.5.1 (17) dwg - System Storage Drives and Logical Units

A: RAM D: FD1 G: PPIDE0-LU2
B: ROM E: PPIDE0-LU0 H: PPIDE0-LU3
C: FD0 F: PPIDE0-LU1

Current drive is E: Number of LUs is 7 infolist.version 2

LU P -----Label------ LU P -----Label------ LU P -----Label------
0 [multiformatted] 1 [multiformatted] 2 [multiformatted]
3 [multiformatted] 4 [multiformatted] 5 [multiformatted]
6 [multiformatted]

Options( N(ext), P(revious), Q(uit) )?

[/QUOTE]
This is regardless of the fact that I told MULTIFMT to format LU 0 to LU31
(which it appeared to do).

Am I missing something?

The startup message is (in part):

[QUOTE]
CP/M-80 2.2C for ZETA Z80 SBC
CBIOS v2.1.1 (RomWBW-WWarthen-120828T0822), FLOPPY (AUTOSIZE), PPIDE (STD)
[/QUOTE]

Maybe I need an upgrade of the ROM and/or the system that's on my boot
floppy?

Regards, Bob Devries
Dalby, QLD, Australia

----- Original Message -----
From: Douglas Goodall
To: n8vem-/***@public.gmane.org
Cc: Wayne Ingram
Sent: Monday, October 14, 2013 4:14 PM
Subject: Re: [N8VEM: 16263] Hard disk image for the N8VEM


Bob,


A little background…


When you are starting with a chip whose contents are unknown, you want to
prepare
the chip in two respects. First there is the preparation of the directory
entries which
get filled with E5's, and secondly there is a sector of metadata which
includes a label
and some other stuff.


Multifmt does both, leaving you with a set of empty directories and default
metadata.


After this you can copy files onto the various logical units and user
numbers.


During the preparation of the .DAT file, this should have been done,


If you are using a .dat file, you should not need to format the chip in any
way as all
that will be overwritten.


I don't know if the current .dat file was prepared in this way. If not the
metadata might
not be there.


When you say you are not seeing the logical units you expect, are those
logical units
you are looking for or user numbers?


Regards,
Douglas


On Oct 13, 2013, at 7:02 PM, Bob Devries <devries.bob-***@public.gmane.org> wrote:


Hi Douglas,

I'm having a problem using the hard disk image with my ZETA, using PPIDE. I
copied the .DAT file to a 1GiB CF card, and I can access it, but I don't see
all the logical units as named in the document.

I tried MULTIFMT, but it doesn't erase the CF card.

I'm using v 2.5.1 of ROMWBW; not quite the latest, but I thought it should
work. Is there any special magic words I need to use? ;)

I use a PC programme called DISKIMAGE to copy the .DAT filr to the CF card.
Should I format the card first?

Regards, Bob Devries
Dalby, QLD, Australia

----- Original Message -----
From: Douglas Goodall
To: n8vem-/***@public.gmane.org
Sent: Tuesday, October 08, 2013 10:24 PM
Subject: Re: [N8VEM: 16245] Hard disk image for the N8VEM


Hi Oscar,


I believe I just downloaded the dat file ok.


The default device size for SD and CF is 64MB.


7 = 64 / 9


That gives us seven logical units on a 64MB chip.


So beyond the four logical drives that are mapped by default
to LU0,LU1,LU2,LU3, the MAP command can access all seven
of the logical units.


I would use multifmt to prepare a 64MB chip, then load away.


This way you can use all of the 64MB chip, and not just the first 32MB
(actually the first 36MB).




On Oct 7, 2013, at 2:56 PM, oscarv <vermeulen.oscar-***@public.gmane.org> wrote:


Hi,

Somehow I never quite got around to loading up a N8VEM hard disk image with
all the classic CP/M software, and I'd expect that goes for more people.

But then I had to prepare something nice to showcase the N8VEM at the VCFe
last weekend. So I finally spent a few (more than a few, in the end) hours
filling a disk image. If you want, you can download this image here, and a
small booklet with descriptions here. As it is for RomWBW, it'll work on SDs
and CFs, on the N8VEM and the Zeta. It's certainly neither perfect nor
complete, but it holds all the big languages and applications so it's a
start.

BTW, the VCFe exhibit itself is described here.

Cheers,

Oscar.
--
You received this message because you are subscribed to the Google Groups
"N8VEM" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to n8vem+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To post to this group, send email to n8vem-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
Visit this group at http://groups.google.com/group/n8vem.
For more options, visit https://groups.google.com/groups/opt_out.



---
Douglas Goodall
doug-***@public.gmane.org
http://goodall.us.com
WQRLl515
--
You received this message because you are subscribed to the Google Groups
"N8VEM" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to n8vem+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To post to this group, send email to n8vem-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
Visit this group at http://groups.google.com/group/n8vem.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups
"N8VEM" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to n8vem+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To post to this group, send email to n8vem-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
Visit this group at http://groups.google.com/group/n8vem.
For more options, visit https://groups.google.com/groups/opt_out.


---
Douglas Goodall
doug-***@public.gmane.org
http://goodall.us.com
WQRLl515
--
You received this message because you are subscribed to the Google Groups
"N8VEM" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to n8vem+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To post to this group, send email to n8vem-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
Visit this group at http://groups.google.com/group/n8vem.
For more options, visit https://groups.google.com/groups/opt_out.

[Douglas Goodall]

Bob,

There is a config item ..

PPIDEENABLE .EQU TRUE ; TRUE FOR PPIDE SUPPORT (DO NOT COMBINE WITH DSKYENABLE)
PPIDEIOB .EQU $60 ; PPIDE IOBASE
PPIDETRACE .EQU 1 ; 0=SILENT, 1=ERRORS, 2=EVERYTHING (ONLY RELEVANT IF PPIDEENABLE = TRUE)
PPIDE8BIT .EQU FALSE ; USE IDE 8BIT TRANSFERS (PROBABLY ONLY WORKS FOR CF CARDS!)
PPIDECAPACITY .EQU 64 ; CAPACITY OF DEVICE (IN MB)
PPIDESLOW .EQU FALSE ; ADD DELAYS TO HELP PROBLEMATIC HARDWARE (TRY THIS IF PPIDE IS UNRELIABLE)
;

By default, the maximum size of the PPIDE media is configured at 64MB.

64/9 = 7 aka (0-6)

If you want to use 32 logical units, change PPIDECAPACITY to (32*9)

PPIDECAPACITY .EQU (32*9) ; CAPACITY OF DEVICE (IN MB)

and rebuild and update your BIOS. Then things will work for you the way you want.

I forget exactly how many logical units the BIOS accesses before there is trouble
in the address math. I usually set mine for 200 or 220…

PPIDECAPACITY .EQU (200*9) ; CAPACITY OF DEVICE (IN MB)
or
PPIDECAPACITY .EQU (220*9) ; CAPACITY OF DEVICE (IN MB)

for use with a 2GB chip.


The results in the MAP commend look perfect. The fact that the LU labels are
showing as "multi formatted" means each of the logical units has it's properly
formatted metadata.

It is not necessary to format the card in Windows first, as multifmt overwrites
the volume structure from Windows anyway.

SO anyway, reconfigure, rebuild, reflash (or reburn), and get back to me with
your new observations.

I believe the CPMNAME command will show you the currently assembled in
configuration details, such as the pride capacity.

Regards,

Douglas

Post by Bob Devries
Hi Douglas,
Well, I formatted the CF card in Windows, and then plugged it into my ZETA.
I then used MULTIFMT to format it for CP/M.
[QUOTE]
MAP.COM 6/25/2013 v2.5.1 (17) dwg - System Storage Drives and Logical Units
A: RAM D: FD1 G: PPIDE0-LU2
B: ROM E: PPIDE0-LU0 H: PPIDE0-LU3
C: FD0 F: PPIDE0-LU1
Current drive is E: Number of LUs is 7 infolist.version 2
LU P -----Label------ LU P -----Label------ LU P -----Label------
0 [multiformatted] 1 [multiformatted] 2 [multiformatted]
3 [multiformatted] 4 [multiformatted] 5 [multiformatted]
6 [multiformatted]
Options( N(ext), P(revious), Q(uit) )?
[/QUOTE]
This is regardless of the fact that I told MULTIFMT to format LU 0 to LU31 (which it appeared to do).
Am I missing something?
[QUOTE]
CP/M-80 2.2C for ZETA Z80 SBC
CBIOS v2.1.1 (RomWBW-WWarthen-120828T0822), FLOPPY (AUTOSIZE), PPIDE (STD)
[/QUOTE]
Maybe I need an upgrade of the ROM and/or the system that's on my boot floppy?
Regards, Bob Devries
Dalby, QLD, Australia
----- Original Message ----- From: Douglas Goodall
Cc: Wayne Ingram
Sent: Monday, October 14, 2013 4:14 PM
Subject: Re: [N8VEM: 16263] Hard disk image for the N8VEM
Bob,
A little background…
When you are starting with a chip whose contents are unknown, you want to prepare
the chip in two respects. First there is the preparation of the directory entries which
get filled with E5's, and secondly there is a sector of metadata which includes a label
and some other stuff.
Multifmt does both, leaving you with a set of empty directories and default metadata.
After this you can copy files onto the various logical units and user numbers.
During the preparation of the .DAT file, this should have been done,
If you are using a .dat file, you should not need to format the chip in any way as all
that will be overwritten.
I don't know if the current .dat file was prepared in this way. If not the metadata might
not be there.
When you say you are not seeing the logical units you expect, are those logical units
you are looking for or user numbers?
Regards,
Douglas
Hi Douglas,
I'm having a problem using the hard disk image with my ZETA, using PPIDE. I copied the .DAT file to a 1GiB CF card, and I can access it, but I don't see all the logical units as named in the document.
I tried MULTIFMT, but it doesn't erase the CF card.
I'm using v 2.5.1 of ROMWBW; not quite the latest, but I thought it should work. Is there any special magic words I need to use? ;)
I use a PC programme called DISKIMAGE to copy the .DAT filr to the CF card. Should I format the card first?
Regards, Bob Devries
Dalby, QLD, Australia
----- Original Message -----
From: Douglas Goodall
Sent: Tuesday, October 08, 2013 10:24 PM
Subject: Re: [N8VEM: 16245] Hard disk image for the N8VEM
Hi Oscar,
I believe I just downloaded the dat file ok.
The default device size for SD and CF is 64MB.
7 = 64 / 9
That gives us seven logical units on a 64MB chip.
So beyond the four logical drives that are mapped by default
to LU0,LU1,LU2,LU3, the MAP command can access all seven
of the logical units.
I would use multifmt to prepare a 64MB chip, then load away.
This way you can use all of the 64MB chip, and not just the first 32MB (actually the first 36MB).
Hi,
Somehow I never quite got around to loading up a N8VEM hard disk image with all the classic CP/M software, and I'd expect that goes for more people.
But then I had to prepare something nice to showcase the N8VEM at the VCFe last weekend. So I finally spent a few (more than a few, in the end) hours filling a disk image. If you want, you can download this image here, and a small booklet with descriptions here. As it is for RomWBW, it'll work on SDs and CFs, on the N8VEM and the Zeta. It's certainly neither perfect nor complete, but it holds all the big languages and applications so it's a start.
BTW, the VCFe exhibit itself is described here.
Cheers,
Oscar.
--
You received this message because you are subscribed to the Google Groups "N8VEM" group.
Visit this group at http://groups.google.com/group/n8vem.
For more options, visit https://groups.google.com/groups/opt_out.
---
Douglas Goodall
http://goodall.us.com
WQRLl515
--
You received this message because you are subscribed to the Google Groups "N8VEM" group.
Visit this group at http://groups.google.com/group/n8vem.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups "N8VEM" group.
Visit this group at http://groups.google.com/group/n8vem.
For more options, visit https://groups.google.com/groups/opt_out.
---
Douglas Goodall
http://goodall.us.com
WQRLl515
--
You received this message because you are subscribed to the Google Groups "N8VEM" group.
Visit this group at http://groups.google.com/group/n8vem.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups "N8VEM" group.
Visit this group at http://groups.google.com/group/n8vem.
For more options, visit https://groups.google.com/groups/opt_out.

---
Douglas Goodall
doug-***@public.gmane.org
http://goodall.us.com
WQRLl515

[Bob Devries]

Douglas,
I rebuilt the ROM with the config you suggested.
Here's the output of CPMNAME:

[QUOTE]
CPMNAME.COM 6/25/2013 v2.5.1 (17) dwg - Display System Configuration

CP/M-80 2.2 for ZETA Z80, CBIOS v2.5.1

ZETA Z80 @ 20MHz, RAM=512MB, ROM=512MB
RomWBW Version 2.5.1.17, 15/10/2013
Disk Boot Device=FD, Unit=0, LU=16

Console: Default=UART:0, Alternate=UART:0, Init Baudrate=38400
Default Video Display: *None*, Default Emulation: TTY
Current Terminal Type: ANSI
Default IO Byte=0x00, Alternate IO Byte=0x00
Disk Write Caching=True, Disk IO Tracing=False
Disk Mapping Priority: RAM, Clear RAM Disk: Auto

DSKY Disabled
UART Enabled
UART0 FIFO=True, AFC=False, Baudrate=38400
ASCI Disabled
VDU Disabled
CVDU Disabled
UPD7220 Disabled
N8V Disabled

FD Enabled, Mode=ZETA, TraceLevel=1, Media=1.44M/720K, Auto=True
IDE Disabled, Mode=DIO, TraceLevel=1, 8bit=False, Size=64MB
PPIDE Enabled, IOBase=0x60, TraceLevel=1, 8bit=False, Slow=False, Size=1980MB
PRP Disabled, SD Enabled, TraceLevel=1, Size=64MB, Console Enabled
PPP Disabled, SD Enabled, TraceLevel=1, Size=64MB, Console Enabled
HDSK Disabled, TraceLevel=1, Size=64MB

PPK Disabled, TraceLevel=1
KBD Disabled, TraceLevel=1

TTY Disabled
ANSI Disabled, TraceLevel=1
[/QUOTE]

I copied the file CForSDImage.dat to a 1GiB CF card.
I still don't get any files beyound LU 7. I get LU 0 to 3 by default in drives E:-H:, and I can use MAP to change those to LU 4-6, but LU 5-6 return NO FILES.

Am I seeing a problem related to the original CF card size? What I'm saying is, if I copied the data from a CF with 32 LU units, and put it on a CF with 200 LU units, would it work correctly?

Regards, Bob Devries
Dalby, QLD, Australia

[Douglas Goodall]

I didn't create the dat file so I don't know it's limitations,
but from the look of things, I would expect the logical units
to work.

By the way, you can use multifmt to format specific ranges of logical units.

You don't have to start with zero or end in any particular place.

Douglas

Post by oscarv
Douglas,
I rebuilt the ROM with the config you suggested.
[QUOTE]
CPMNAME.COM 6/25/2013 v2.5.1 (17) dwg - Display System Configuration
CP/M-80 2.2 for ZETA Z80, CBIOS v2.5.1
RomWBW Version 2.5.1.17, 15/10/2013
Disk Boot Device=FD, Unit=0, LU=16
Console: Default=UART:0, Alternate=UART:0, Init Baudrate=38400
Default Video Display: *None*, Default Emulation: TTY
Current Terminal Type: ANSI
Default IO Byte=0x00, Alternate IO Byte=0x00
Disk Write Caching=True, Disk IO Tracing=False
Disk Mapping Priority: RAM, Clear RAM Disk: Auto
DSKY Disabled
UART Enabled
UART0 FIFO=True, AFC=False, Baudrate=38400
ASCI Disabled
VDU Disabled
CVDU Disabled
UPD7220 Disabled
N8V Disabled
FD Enabled, Mode=ZETA, TraceLevel=1, Media=1.44M/720K, Auto=True
IDE Disabled, Mode=DIO, TraceLevel=1, 8bit=False, Size=64MB
PPIDE Enabled, IOBase=0x60, TraceLevel=1, 8bit=False, Slow=False, Size=1980MB
PRP Disabled, SD Enabled, TraceLevel=1, Size=64MB, Console Enabled
PPP Disabled, SD Enabled, TraceLevel=1, Size=64MB, Console Enabled
HDSK Disabled, TraceLevel=1, Size=64MB
PPK Disabled, TraceLevel=1
KBD Disabled, TraceLevel=1
TTY Disabled
ANSI Disabled, TraceLevel=1
[/QUOTE]
I copied the file CForSDImage.dat to a 1GiB CF card.
I still don't get any files beyound LU 7. I get LU 0 to 3 by default in drives E:-H:, and I can use MAP to change those to LU 4-6, but LU 5-6 return NO FILES.
Am I seeing a problem related to the original CF card size? What I'm saying is, if I copied the data from a CF with 32 LU units, and put it on a CF with 200 LU units, would it work correctly?
Regards, Bob Devries
Dalby, QLD, Australia
--
You received this message because you are subscribed to the Google Groups "N8VEM" group.
Visit this group at http://groups.google.com/group/n8vem.
For more options, visit https://groups.google.com/groups/opt_out.

---
Douglas Goodall
doug-***@public.gmane.org
http://goodall.us.com
WQRLl515

[oscarv]

Bob,

From what i read things are as they should be. The disk image is for a 64mb drive so yes, you can save it on any higher-capacity card but unless you add LUs with multifmt, you only see the 7 LUs that are on the first 64 mb.

I believe that multifmt allows you to then add more LUs after saving the 64mb image on a bigger card, but can't test it right now. It would be logical for MAP not to see beyond the original 7 though: if i remember correctly, the metadata saved for *each* LU contains a field that stores the highest available LU and if you use multifmt to add extra LUs it does not edit the metadata for the original 7 if you have protected them.

Other details: the image was made on simh using multifmt. Only the first four LUs contain software - that was more than enough. I'm now working on a full proper ZSystem which will fill the fifth LU. Note that romWBW provides zcpr 1.0, but zcpr 3.4 with all its support utilities is much nicer!

[Wayne Warthen]

Hi Oscar,

I am very happy to hear you are working through the ZCPR3.4 stuff. It
works great. A pre-built LU on your new CF image would make it really easy
to use.

Thanks!

Wayne

Bob,
From what i read things are as they should be. The disk image is for a
64mb drive so yes, you can save it on any higher-capacity card but unless
you add LUs with multifmt, you only see the 7 LUs that are on the first 64
mb.
I believe that multifmt allows you to then add more LUs after saving the
64mb image on a bigger card, but can't test it right now. It would be
logical for MAP not to see beyond the original 7 though: if i remember
correctly, the metadata saved for *each* LU contains a field that stores
the highest available LU and if you use multifmt to add extra LUs it does
not edit the metadata for the original 7 if you have protected them.
Other details: the image was made on simh using multifmt. Only the first
four LUs contain software - that was more than enough. I'm now working on a
full proper ZSystem which will fill the fifth LU. Note that romWBW provides
zcpr 1.0, but zcpr 3.4 with all its support utilities is much nicer!

[Bob Devries]

Hi Oscar, Douglas & Wayne,

Post by oscarv
Only the first four LUs contain software - that was more than enough.

This comment flies in the face of the document "N8VEM_DEMODISK
DIRECTORY.PDF" which I had assumed to be a description of the software on
the .DAT file in the archive of the same name.
Obviously I was mistaken.

I would love to see ZIP files of the software mentioned in that PDF file.

Regards, Bob Devries
Dalby, QLD, Australia


----- Original Message -----
From: "oscarv" <vermeulen.oscar-***@public.gmane.org>
To: <n8vem-/***@public.gmane.org>
Sent: Wednesday, October 16, 2013 12:43 AM
Subject: Re: [N8VEM: 16273] Hard disk image for the N8VEM


Bob,

Post by oscarv
From what i read things are as they should be. The disk image is for a 64mb

drive so yes, you can save it on any higher-capacity card but unless you add
LUs with multifmt, you only see the 7 LUs that are on the first 64 mb.

I believe that multifmt allows you to then add more LUs after saving the
64mb image on a bigger card, but can't test it right now. It would be
logical for MAP not to see beyond the original 7 though: if i remember
correctly, the metadata saved for *each* LU contains a field that stores the
highest available LU and if you use multifmt to add extra LUs it does not
edit the metadata for the original 7 if you have protected them.

Other details: the image was made on simh using multifmt. Only the first
four LUs contain software - that was more than enough. I'm now working on a
full proper ZSystem which will fill the fifth LU. Note that romWBW provides
zcpr 1.0, but zcpr 3.4 with all its support utilities is much nicer!

[oscarv]

Bob,

Post by Bob Devries
DIRECTORY.PDF" which I had assumed to
be a description of the software on
the .DAT file in the archive of the same name.

The assumption is correct: note that the pdf only refers to software on drives c/d/e/f, so the first four LUs (unless you map in the higher LUs on these drive letters yourself afterwards). The various programs can be found where the pdf says they are - I just checked to be sure.

The zip file with stuff you mention is the 4th download on the page on my site. It holds all the cpm files as well as cpmtools and simh.

Regards,

Oscar

[Bob Devries]

Oscar,
Could you point me to your website? The only links I have are from an
earlier message from you, which point to docs.google.com

Regards, Bob Devries
Dalby, QLD, Australia

----- Original Message -----
From: "oscarv" <vermeulen.oscar-***@public.gmane.org>
To: <n8vem-/***@public.gmane.org>
Sent: Wednesday, October 16, 2013 8:57 AM
Subject: Re: [N8VEM: 16281] Hard disk image for the N8VEM


Bob,

Post by Bob Devries
DIRECTORY.PDF" which I had assumed to
be a description of the software on
the .DAT file in the archive of the same name.

The assumption is correct: note that the pdf only refers to software on
drives c/d/e/f, so the first four LUs (unless you map in the higher LUs on
these drive letters yourself afterwards). The various programs can be found
where the pdf says they are - I just checked to be sure.

The zip file with stuff you mention is the 4th download on the page on my
site. It holds all the cpm files as well as cpmtools and simh.

Regards,

Oscar

[Douglas Goodall]

Wayne W,

Points for you figuring out the non-updated media issue. I was stumped as to why MAP would fail
to list all the LU's.

I haven't looked at the code for a while and I wasn't sure if you had any buffers based on the capacity
field or whether it could be changed at random (dynamically) without harm. The reason I embraced the
existence of the capacity field in the BIOS was so we could have an authoritative limit to the number of
LU's in order not to go running off the end of the media and display bogus logical unit labels.

I agree that the constant mismatch between the assembled in capacity and the size of devices inserted
into the system is a problem.

One possible was to deal with this without changing a bunch of stuff would be to detect the media size
on first select and poke the media size (modulo (MAXNUMLUS*9) into the capacity field. The only trouble there
is that utilities would then assume some number of trailing LU's were valid even if they had not been
prepared and in possession of valid metadata. Because of limitations in the address math, setting the capacity
higher than around 220*9 could allow use of LU's that would malfunction. One way around this would be to go
to wider address math in the LBA calculations. Then we could set the capacity to the detected device size and
the only remaining issue would be unformatted LU's (without metadata).

If we had a user procedure guideline that the first time a new device is used, multifmt should be run, multifmt
would format the true number of LU's based on dynamically set capacity derived from device size on first select.

Douglas

Post by Douglas Goodall
Oscar,
Could you point me to your website? The only links I have are from an earlier message from you, which point to docs.google.com
Regards, Bob Devries
Dalby, QLD, Australia
Sent: Wednesday, October 16, 2013 8:57 AM
Subject: Re: [N8VEM: 16281] Hard disk image for the N8VEM
Bob,

Post by Bob Devries
DIRECTORY.PDF" which I had assumed to
be a description of the software on
the .DAT file in the archive of the same name.

The assumption is correct: note that the pdf only refers to software on drives c/d/e/f, so the first four LUs (unless you map in the higher LUs on these drive letters yourself afterwards). The various programs can be found where the pdf says they are - I just checked to be sure.
The zip file with stuff you mention is the 4th download on the page on my site. It holds all the cpm files as well as cpmtools and simh.
Regards,
Oscar
--
You received this message because you are subscribed to the Google Groups "N8VEM" group.
Visit this group at http://groups.google.com/group/n8vem.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups "N8VEM" group.
Visit this group at http://groups.google.com/group/n8vem.
For more options, visit https://groups.google.com/groups/opt_out.

---
Douglas Goodall
doug-***@public.gmane.org
http://goodall.us.com
WQRLl515

[opticpow]

Doug, Wayne W et. al,

This prompts a question i have since playing with this stuff. If the CBIOS
is loaded from the selected boot device, Could I potentially have a
different compiled in number for each device if I booted from device? For
example, if I plug in a hard disk, it could be sysgen'ed with a CBIOS with
the 200 LU's defined, whereas a floppy disk would only have the number
supported by the floppy?

In this situation, does that mean that only the monitor is being executed
from ROM?

Sorry if this sounds simplistic, still feeling my way around!

Doug, I like the idea of putting the size of the device, or number of LUs
on the actual media. Even if I had to define this myself when I multifmt
the media, I think it is a more elegant solution to different boot images.
I'd love to have a go at this myself, but alas I'm not there yet!

Wayne I.

Post by Douglas Goodall
Wayne W,
Points for you figuring out the non-updated media issue. I was stumped as
to why MAP would fail
to list all the LU's.
I haven't looked at the code for a while and I wasn't sure if you had any
buffers based on the capacity
field or whether it could be changed at random (dynamically) without harm.
The reason I embraced the
existence of the capacity field in the BIOS was so we could have an
authoritative limit to the number of
LU's in order not to go running off the end of the media and display bogus
logical unit labels.
I agree that the constant mismatch between the assembled in capacity and
the size of devices inserted
into the system is a problem.
One possible was to deal with this without changing a bunch of stuff would
be to detect the media size
on first select and poke the media size (modulo (MAXNUMLUS*9) into the
capacity field. The only trouble there
is that utilities would then assume some number of trailing LU's were
valid even if they had not been
prepared and in possession of valid metadata. Because of limitations in
the address math, setting the capacity
higher than around 220*9 could allow use of LU's that would malfunction.
One way around this would be to go
to wider address math in the LBA calculations. Then we could set the
capacity to the detected device size and
the only remaining issue would be unformatted LU's (without metadata).
If we had a user procedure guideline that the first time a new device is
used, multifmt should be run, multifmt
would format the true number of LU's based on dynamically set capacity
derived from device size on first select.
Douglas
Oscar,
Could you point me to your website? The only links I have are from an
earlier message from you, which point to docs.google.com
Regards, Bob Devries
Dalby, QLD, Australia
Sent: Wednesday, October 16, 2013 8:57 AM
Subject: Re: [N8VEM: 16281] Hard disk image for the N8VEM
Bob,
DIRECTORY.PDF" which I had assumed to
be a description of the software on
the .DAT file in the archive of the same name.
The assumption is correct: note that the pdf only refers to software on
drives c/d/e/f, so the first four LUs (unless you map in the higher LUs on
these drive letters yourself afterwards). The various programs can be found
where the pdf says they are - I just checked to be sure.
The zip file with stuff you mention is the 4th download on the page on my
site. It holds all the cpm files as well as cpmtools and simh.
Regards,
Oscar
--
You received this message because you are subscribed to the Google Groups "N8VEM" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at http://groups.google.com/group/n8vem.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups "N8VEM" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at http://groups.google.com/group/n8vem.
For more options, visit https://groups.google.com/groups/opt_out.
---
Douglas Goodall
http://goodall.us.com
WQRLl515

[Douglas Goodall]

Post by opticpow
Doug, Wayne W et. al,
This prompts a question i have since playing with this stuff.
If the CBIOS is loaded from the selected boot device, Could I potentially have a different compiled in number for each device if I booted from device? For example, if I plug in a hard disk, it could be sysgen'ed with a CBIOS with the 200 LU's defined, whereas a floppy disk would only have the number supported by the floppy?

Floppies don't get logical units, only mass storage, PPIDE-> SD CF...

Post by opticpow
In this situation, does that mean that only the monitor is being executed from ROM?
Sorry if this sounds simplistic, still feeling my way around!
Doug, I like the idea of putting the size of the device, or number of LUs on the actual media. Even if I had to define this myself when I multifmt the media, I think it is a more elegant solution to different boot images. I'd love to have a go at this myself, but alas I'm not there yet!

Wayne-I,

Here is how I work with Wayne-W…

I work out my design ideas, then run them past him. He is the senior architect of RomWBW and even in areas
that are not fully fleshed out, he has good ideas about design considerations. It is important to get him to buy
into your design (or work out something with him) if you want your stuff to be in the main-line product.

For instance, you probably want to put the device size in the metadata of the first logical unit. So go look in
thew code and see what the metadata has in it. I think the best way to go is to have the BIOS detect the
device size and use that information, instead of depending on the user to provide it.

You will notice that multifmt is cautious about formatting logical unit zero. One of the reasons for this is because
many builders bring up their first directory by using CLEARDIR and not having any metadata. YOu can quickly
clear several drives worth and get some things going. If they run multifmt and don't realize it, they wipe out their
first drive and become unhappy.

Once you become comfortable with multifmt, it begins acting as a powerful agent on your behalf, quickly conditioning
the entire device.

We might want to have a utility that senses the device capacity and updates the metadata in the first LU.

Do you know how to use subversion?

Douglas

Post by opticpow
Wayne I.
Wayne W,
Points for you figuring out the non-updated media issue. I was stumped as to why MAP would fail
to list all the LU's.
I haven't looked at the code for a while and I wasn't sure if you had any buffers based on the capacity
field or whether it could be changed at random (dynamically) without harm. The reason I embraced the
existence of the capacity field in the BIOS was so we could have an authoritative limit to the number of
LU's in order not to go running off the end of the media and display bogus logical unit labels.
I agree that the constant mismatch between the assembled in capacity and the size of devices inserted
into the system is a problem.
One possible was to deal with this without changing a bunch of stuff would be to detect the media size
on first select and poke the media size (modulo (MAXNUMLUS*9) into the capacity field. The only trouble there
is that utilities would then assume some number of trailing LU's were valid even if they had not been
prepared and in possession of valid metadata. Because of limitations in the address math, setting the capacity
higher than around 220*9 could allow use of LU's that would malfunction. One way around this would be to go
to wider address math in the LBA calculations. Then we could set the capacity to the detected device size and
the only remaining issue would be unformatted LU's (without metadata).
If we had a user procedure guideline that the first time a new device is used, multifmt should be run, multifmt
would format the true number of LU's based on dynamically set capacity derived from device size on first select.
Douglas

Post by Douglas Goodall
Oscar,
Could you point me to your website? The only links I have are from an earlier message from you, which point to docs.google.com
Regards, Bob Devries
Dalby, QLD, Australia
Sent: Wednesday, October 16, 2013 8:57 AM
Subject: Re: [N8VEM: 16281] Hard disk image for the N8VEM
Bob,

Post by Bob Devries
DIRECTORY.PDF" which I had assumed to
be a description of the software on
the .DAT file in the archive of the same name.

The assumption is correct: note that the pdf only refers to software on drives c/d/e/f, so the first four LUs (unless you map in the higher LUs on these drive letters yourself afterwards). The various programs can be found where the pdf says they are - I just checked to be sure.
The zip file with stuff you mention is the 4th download on the page on my site. It holds all the cpm files as well as cpmtools and simh.
Regards,
Oscar
--
You received this message because you are subscribed to the Google Groups "N8VEM" group.
Visit this group at http://groups.google.com/group/n8vem.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups "N8VEM" group.
Visit this group at http://groups.google.com/group/n8vem.
For more options, visit https://groups.google.com/groups/opt_out.

---
Douglas Goodall
http://goodall.us.com
WQRLl515
--
You received this message because you are subscribed to the Google Groups "N8VEM" group.
Visit this group at http://groups.google.com/group/n8vem.
For more options, visit https://groups.google.com/groups/opt_out.

---
Douglas Goodall
doug-***@public.gmane.org
http://goodall.us.com
WQRLl515

[Wayne Warthen]

I think Douglas answered a lot of this, but want to add a few things... see
below.

Post by opticpow
Doug, Wayne W et. al,
This prompts a question i have since playing with this stuff. If the CBIOS
is loaded from the selected boot device, Could I potentially have a
different compiled in number for each device if I booted from device? For
example, if I plug in a hard disk, it could be sysgen'ed with a CBIOS with
the 200 LU's defined, whereas a floppy disk would only have the number
supported by the floppy?

Douglas is right that floppies do not have LU's. However, if you are
getting at the idea that the drive letter configuration (and LU count)
could be different for different boot devices, you are right! Although the
hardware drivers are contained in the ROM BIOS, there is still the CPM BIOS
which is located on the system area of the boot device. So, you could
configure different system images with different drive configurations and
SYSGEN them onto different boot devices. The drive configuration would
then be based on which device you boot from. CPM 2.2 was never built with
any concept of dynamic drive letter assignment. As far as CPM is concerned
the drive configuration for a machine is intended to be completed fixed and
hard-coded. This is why there are some oddities to disk device management
when you try to combine new, high capacity media with an older OS.

Post by opticpow
In this situation, does that mean that only the monitor is being executed
from ROM?

Kind of right. More accurate to say that the BIOS is split into two parts.
One part (HBIOS) is in the ROM always. It contains the banked driver
code. The other part is the CPM BIOS which is loaded from the system
tracks of the boot device.

Post by opticpow
Sorry if this sounds simplistic, still feeling my way around!

No problem, your questions help everyone.

Post by opticpow
Doug, I like the idea of putting the size of the device, or number of LUs
on the actual media. Even if I had to define this myself when I multifmt
the media, I think it is a more elegant solution to different boot images.
I'd love to have a go at this myself, but alas I'm not there yet!

I was already in the process of a fairly complete overhaul of the entire
boot, drive, and LU management mechanism. I think my changes will greatly
improve this situation, but it is an evolving effort and will definitely
take a while based on my current time availability. Regardless, I am
committed to doing it, so hand in there. As Douglas says, the process
starts with the BIOS which is then followed by updating of the utilities.
What I am finding is that this change is pretty simple in the BIOS, but
will cause a pretty involved overhaul of the utilities.

Post by opticpow
Wayne I.

Post by Douglas Goodall
Wayne W,
Points for you figuring out the non-updated media issue. I was stumped as
to why MAP would fail
to list all the LU's.
I haven't looked at the code for a while and I wasn't sure if you had any
buffers based on the capacity
field or whether it could be changed at random (dynamically) without
harm. The reason I embraced the
existence of the capacity field in the BIOS was so we could have an
authoritative limit to the number of
LU's in order not to go running off the end of the media and display
bogus logical unit labels.
I agree that the constant mismatch between the assembled in capacity and
the size of devices inserted
into the system is a problem.
One possible was to deal with this without changing a bunch of stuff
would be to detect the media size
on first select and poke the media size (modulo (MAXNUMLUS*9) into the
capacity field. The only trouble there
is that utilities would then assume some number of trailing LU's were
valid even if they had not been
prepared and in possession of valid metadata. Because of limitations in
the address math, setting the capacity
higher than around 220*9 could allow use of LU's that would malfunction.
One way around this would be to go
to wider address math in the LBA calculations. Then we could set the
capacity to the detected device size and
the only remaining issue would be unformatted LU's (without metadata).
If we had a user procedure guideline that the first time a new device is
used, multifmt should be run, multifmt
would format the true number of LU's based on dynamically set capacity
derived from device size on first select.
Douglas
Oscar,
Could you point me to your website? The only links I have are from an
earlier message from you, which point to docs.google.com
Regards, Bob Devries
Dalby, QLD, Australia
Sent: Wednesday, October 16, 2013 8:57 AM
Subject: Re: [N8VEM: 16281] Hard disk image for the N8VEM
Bob,
DIRECTORY.PDF" which I had assumed to
be a description of the software on
the .DAT file in the archive of the same name.
The assumption is correct: note that the pdf only refers to software on
drives c/d/e/f, so the first four LUs (unless you map in the higher LUs on
these drive letters yourself afterwards). The various programs can be found
where the pdf says they are - I just checked to be sure.
The zip file with stuff you mention is the 4th download on the page on my
site. It holds all the cpm files as well as cpmtools and simh.
Regards,
Oscar
--
You received this message because you are subscribed to the Google Groups "N8VEM" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at http://groups.google.com/group/n8vem.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups "N8VEM" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at http://groups.google.com/group/n8vem.
For more options, visit https://groups.google.com/groups/opt_out.
---
Douglas Goodall
http://goodall.us.com
WQRLl515

[opticpow]

Thanks Doug & Wayne. Replies below....

Post by Wayne Warthen
Douglas is right that floppies do not have LU's. However, if you are
getting at the idea that the drive letter configuration (and LU count)
could be different for different boot devices, you are right! Although the
hardware drivers are contained in the ROM BIOS, there is still the CPM BIOS
which is located on the system area of the boot device. So, you could
configure different system images with different drive configurations and
SYSGEN them onto different boot devices. The drive configuration would
then be based on which device you boot from. CPM 2.2 was never built with
any concept of dynamic drive letter assignment. As far as CPM is concerned
the drive configuration for a machine is intended to be completed fixed and
hard-coded. This is why there are some oddities to disk device management
when you try to combine new, high capacity media with an older OS.

Thanks, it confirms I'm getting this, and not so much off in the weeds with
my understanding. In regards to the floppy, yeah a mental slip there, I was
actually thinking of a IDE based ZIP disk. It does sort of look like a
floppy :p

Post by Wayne Warthen

Post by opticpow
In this situation, does that mean that only the monitor is being executed
from ROM?

Kind of right. More accurate to say that the BIOS is split into two
parts. One part (HBIOS) is in the ROM always. It contains the banked
driver code. The other part is the CPM BIOS which is loaded from the
system tracks of the boot device.

I'd love to read more about this if you have any pointers?

Post by Wayne Warthen
Sorry if this sounds simplistic, still feeling my way around!
No problem, your questions help everyone.

I've found that the mailing list has a treasure trove of information, and
I have been reading as much as the list history as I can to get up to
speed. I have the idea that I'd like to document my experience for other
new builders, and make some of the information in the mailing list easier
to find for us newbies.I sure pretty much every problem I have experienced
thus far, has been found & solved by builders before me!

Post by Wayne Warthen
I was already in the process of a fairly complete overhaul of the entire
boot, drive, and LU management mechanism. I think my changes will greatly
improve this situation, but it is an evolving effort and will definitely
take a while based on my current time availability. Regardless, I am
committed to doing it, so hand in there. As Douglas says, the process
starts with the BIOS which is then followed by updating of the utilities.
What I am finding is that this change is pretty simple in the BIOS, but
will cause a pretty involved overhaul of the utilities.

Sounds like it will be a worthwhile improvement.

Doug, you asked if I know svn. Yes, and I have already downloaded RomWBW,
but it seems to be too far over my head at the moment. (I only used CP/M in
the 80's, too young to do any coding) Maybe starting with a simple ROM
source my be a better place to start?

Wayne I

[Wayne Warthen]

Hi Wayne,

There are a couple of useful documents in the Docs directory of the RomWBW
distribution.

First of all, there is the CP/M 2.2 Operating System Manual (cpm22-m.pdf in
the Reference subdirectory). Take a look at Chapter 6: CP/M Alteration.
This will help you understand the CP/M CBIOS and how it works.

After you have a handle on CBIOS, you should look at the RomWBW System
Architecture document in the Docs directory of the RomWBW distribution.
The first few pages may help.

--Wayne

Post by opticpow
I'd love to read more about this if you have any pointers?

[Bob Devries]

Hi Douglas,

Strange as it may seem, it appears that my CF card may be faulty. It's a relatively new card (to me anyway) badged AMICROE CF 1GB (133x). I noticed that I'm getting other failures besides what I described. I have another CF card which I had been using, and it doesn't have any problems (no corruption).

However, when I type MAP, only LU0 to LU6 are displayed.

I used Multifmt to format LU 7 to 31, and if I use MAP to set (e.g.) drive H: to LU 16, I can copy files across, and retrieve them. Something is still not quite kosher, in that I can't seem to display the LU beyond 6 using MAP.

Do you have an incantation for this malady? :-)

Regards, Bob Devries
Dalby, QLD, Australia

[Douglas Goodall]

Bob,

Oaff the top of my head I can't explain it. I am planning on re-connecting my N8-2312 shortly and
'I will examine MAP to make sure it hasn't become broken. I am concerned because MAP is surely
supposed to display subsequent logical unit labels.

By the way, it is possible to use META to traverse the logical units, examining the logical unit labels.
It is actually a good tool for verifying the proper functioning of the logical units. Also it is the tool which
has the capability of setting the protect attribute on a specific logical unit.

If the metadata of the logical units beyond 6 is ok, then the problem with MAP is just that, an inability
to display the logical unit labels.

I will keep you informed.

Douglas

Post by Bob Devries
Hi Douglas,
Strange as it may seem, it appears that my CF card may be faulty. It's a relatively new card (to me anyway) badged AMICROE CF 1GB (133x). I noticed that I'm getting other failures besides what I described. I have another CF card which I had been using, and it doesn't have any problems (no corruption).
However, when I type MAP, only LU0 to LU6 are displayed.
I used Multifmt to format LU 7 to 31, and if I use MAP to set (e.g.) drive H: to LU 16, I can copy files across, and retrieve them. Something is still not quite kosher, in that I can't seem to display the LU beyond 6 using MAP.
Do you have an incantation for this malady? :-)
Regards, Bob Devries
Dalby, QLD, Australia
--
You received this message because you are subscribed to the Google Groups "N8VEM" group.
Visit this group at http://groups.google.com/group/n8vem.
For more options, visit https://groups.google.com/groups/opt_out.

---
Douglas Goodall
doug-***@public.gmane.org
http://goodall.us.com
WQRLl515

[Wayne Warthen]

Hi Bob,

I have been trying to follow this thread and I'm not sure I have been
succesful. I am thinking it might help for me to go through a little bit
of how the whole LU thing works within RomWBW. I am not sure that you are
actually having any problems.

To start with, the LU concept is implemented within CBIOS. It may be
counter-intuitive, but the number of LU's for a device (like PPIDE) is
defined in the ROM itself. This number is not specified directly, but
instead it is derived from the device capacity that is defined int he
config_ files in the build. As Douglas has mentioned, the default capacity
in the pre-built ROMs is 64MB. Based on the space required for a CP/M
drive (a bit more that 8MB), this means that by default the LU count for
all drives will be 7 (referred to as LU0 thru LU6).

So, keep in mind that no matter what size CF card you plug into your
system, the ROM will still assume there are 7 LU's (unless you change the
configuration and build a new ROM -- I will go into that in a minute).

With that said, let's talk about the utilities for a minute.

As Douglas has described, MULTIFMT will prepare your CF card to be used by
setting up the directories on the LU's. By default, MULTIFMT will "ask"
the ROM how many LU's there are. It will then suggest that you format that
number of LU's. All of this makes sense. However, you will find that you
can override the prompted defaults in MULTIFMT and specify LU values
greater than the ROM was configured for. So, for example, I could tell
MULTIFMT to format LU7 even though the ROM was configured for LU0-LU6!
MULTIFMT will dutifully do as you asked, but it WILL NOT change the number
of LU's that the ROM thinks is on the drive.

OK, so now let's talk about MAP. MAP is a bit similar to MULTIFMT in that
it "asks" the ROM how many LU's are on the drive. Again, the real size of
the device is not relevant, only the size that was configured into the ROM
when it was built. So, when you fire up MAP, it will (for the pre-built
ROMs) show LU0-LU6. Even if you have used MULTIFMT to create LU7, MAP will
not show it because MAP has no idea it is there. MAP is consulting with
the the ROM which still has the LUs defined as LU0-LU6. One more oddity
here... You can force MAP to map a drive to an LU beyond the number that
are configured in the ROM. MAP does not stop you from doing this (it is a
"use at your own risk" kind of thing).

The META utility is also similar. It also "asks" the ROM how many LU's are
on the device and then let's you look at that num ber of LU's. Even if you
formatted additional LU's with MULTIFMT, META will not know they are there
because the ROM has not changed.

OK, so, to recap, the ROM maintains an idea of the number of LU's on each
device which is LU0-LU6 (7 LU's) by default. The utilities will display
the number of LUs that are configured into the ROM. However, the utilities
will generally still let you manage and map LU's beyond the number
configured in the ROM.

Now, regarding Oscar's cool new image. He created his image using a
default ROM build. The image is sized for 7 LU's (0-6) and he has
populated the first 4 LU's with data. The last 3 LU's are simply empty
file systems.

When you copy his image onto a CF Card, it will put 7 LU's worth of data in
place. You could set up additional LU's after the first 7 using MULTIFMT
as you like. If you want MAP, MULTIFMT, and META to "show" more LU's, you
will need to build a custom ROM with the device capacity set for the number
of LU's that you want. You must run MULTIFMT on the added LU's so the
directories are properly formatted.

The next release of RomWBW will move the LU count information onto the
storage device itself which will greatly simplify all this. However, for
now, the thing to remember is that the ROM is configured for a set number
of LU's and believes that number no matter what you do with the utilities.
You can still force the utilities to use LU's beyond the ones the ROM
knows about, but it does not change the number of LU's that the utilities
will indicate are in existence.

Not sure if I have helped, but thought it was worth a shot...

Thanks,

Wayne

[oscarv]

... The nice thing of this current state of things being that you could have your "personal files" stored on LUs above #7 (on a larger card) and they would be preserved whenever you copy a standard 64mb distribution image onto the card.

So updating to a new distribution image becomes trivial and nondestructive (for those with faith and courage, and those who make a safety backup)

Only thing would be that VIEW would not show these higher LUs, but you can use them. i think fixing that view issue is a tiny tweak.

Regards,

Oscar

[Bob Devries]

Wayne, thanks for the detailed explanation.

It seems to me, however, that the utilities do *NOT* correctly get the number of available LU's I modified my ROM code as per Douglas' suggestion, and CPMNAME does show the CF size as 1980MB, but still only 7 LU's are reported by META, MAP, and MULTIFMT. Methinks there's a problem somewhere...

Your suggestion that the number of available LU's be saved on the device makes a lot of sense.

Regards, Bob Devries
Dalby, QLD, Australia

----- Original Message -----
From: Wayne Warthen
To: n8vem-/***@public.gmane.org
Sent: Wednesday, October 16, 2013 5:58 AM
Subject: Re: [N8VEM: 16275] Hard disk image for the N8VEM


Hi Bob,


I have been trying to follow this thread and I'm not sure I have been succesful. I am thinking it might help for me to go through a little bit of how the whole LU thing works within RomWBW. I am not sure that you are actually having any problems.


To start with, the LU concept is implemented within CBIOS. It may be counter-intuitive, but the number of LU's for a device (like PPIDE) is defined in the ROM itself. This number is not specified directly, but instead it is derived from the device capacity that is defined int he config_ files in the build. As Douglas has mentioned, the default capacity in the pre-built ROMs is 64MB. Based on the space required for a CP/M drive (a bit more that 8MB), this means that by default the LU count for all drives will be 7 (referred to as LU0 thru LU6).


So, keep in mind that no matter what size CF card you plug into your system, the ROM will still assume there are 7 LU's (unless you change the configuration and build a new ROM -- I will go into that in a minute).


With that said, let's talk about the utilities for a minute.


As Douglas has described, MULTIFMT will prepare your CF card to be used by setting up the directories on the LU's. By default, MULTIFMT will "ask" the ROM how many LU's there are. It will then suggest that you format that number of LU's. All of this makes sense. However, you will find that you can override the prompted defaults in MULTIFMT and specify LU values greater than the ROM was configured for. So, for example, I could tell MULTIFMT to format LU7 even though the ROM was configured for LU0-LU6! MULTIFMT will dutifully do as you asked, but it WILL NOT change the number of LU's that the ROM thinks is on the drive.


OK, so now let's talk about MAP. MAP is a bit similar to MULTIFMT in that it "asks" the ROM how many LU's are on the drive. Again, the real size of the device is not relevant, only the size that was configured into the ROM when it was built. So, when you fire up MAP, it will (for the pre-built ROMs) show LU0-LU6. Even if you have used MULTIFMT to create LU7, MAP will not show it because MAP has no idea it is there. MAP is consulting with the the ROM which still has the LUs defined as LU0-LU6. One more oddity here... You can force MAP to map a drive to an LU beyond the number that are configured in the ROM. MAP does not stop you from doing this (it is a "use at your own risk" kind of thing).


The META utility is also similar. It also "asks" the ROM how many LU's are on the device and then let's you look at that num ber of LU's. Even if you formatted additional LU's with MULTIFMT, META will not know they are there because the ROM has not changed.


OK, so, to recap, the ROM maintains an idea of the number of LU's on each device which is LU0-LU6 (7 LU's) by default. The utilities will display the number of LUs that are configured into the ROM. However, the utilities will generally still let you manage and map LU's beyond the number configured in the ROM.


Now, regarding Oscar's cool new image. He created his image using a default ROM build. The image is sized for 7 LU's (0-6) and he has populated the first 4 LU's with data. The last 3 LU's are simply empty file systems.


When you copy his image onto a CF Card, it will put 7 LU's worth of data in place. You could set up additional LU's after the first 7 using MULTIFMT as you like. If you want MAP, MULTIFMT, and META to "show" more LU's, you will need to build a custom ROM with the device capacity set for the number of LU's that you want. You must run MULTIFMT on the added LU's so the directories are properly formatted.


The next release of RomWBW will move the LU count information onto the storage device itself which will greatly simplify all this. However, for now, the thing to remember is that the ROM is configured for a set number of LU's and believes that number no matter what you do with the utilities. You can still force the utilities to use LU's beyond the ones the ROM knows about, but it does not change the number of LU's that the utilities will indicate are in existence.


Not sure if I have helped, but thought it was worth a shot...


Thanks,


Wayne

--
You received this message because you are subscribed to the Google Groups "N8VEM" group.
To unsubscribe from this group and stop receiving emails from it, send an email to n8vem+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To post to this group, send email to n8vem-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
Visit this group at http://groups.google.com/group/n8vem.
For more options, visit https://groups.google.com/groups/opt_out.

[Wayne Warthen]

Thanks Bob. That is interesting. I will see if I can track that down.

--Wayne

Post by Bob Devries
Wayne, thanks for the detailed explanation.
It seems to me, however, that the utilities do *NOT* correctly get the
number of available LU's I modified my ROM code as per Douglas' suggestion,
and CPMNAME does show the CF size as 1980MB, but still only 7 LU's are
reported by META, MAP, and MULTIFMT. Methinks there's a problem somewhere...
Your suggestion that the number of available LU's be saved on the device
makes a lot of sense.
Regards, Bob Devries
Dalby, QLD, Australia
----- Original Message -----
*From:* Wayne Warthen <javascript:>
*Sent:* Wednesday, October 16, 2013 5:58 AM
*Subject:* Re: [N8VEM: 16275] Hard disk image for the N8VEM
Hi Bob,
I have been trying to follow this thread and I'm not sure I have been
succesful. I am thinking it might help for me to go through a little bit
of how the whole LU thing works within RomWBW. I am not sure that you are
actually having any problems.
To start with, the LU concept is implemented within CBIOS. It may be
counter-intuitive, but the number of LU's for a device (like PPIDE) is
defined in the ROM itself. This number is not specified directly, but
instead it is derived from the device capacity that is defined int he
config_ files in the build. As Douglas has mentioned, the default capacity
in the pre-built ROMs is 64MB. Based on the space required for a CP/M
drive (a bit more that 8MB), this means that by default the LU count for
all drives will be 7 (referred to as LU0 thru LU6).
So, keep in mind that no matter what size CF card you plug into your
system, the ROM will still assume there are 7 LU's (unless you change the
configuration and build a new ROM -- I will go into that in a minute).
With that said, let's talk about the utilities for a minute.
As Douglas has described, MULTIFMT will prepare your CF card to be used by
setting up the directories on the LU's. By default, MULTIFMT will "ask"
the ROM how many LU's there are. It will then suggest that you format that
number of LU's. All of this makes sense. However, you will find that you
can override the prompted defaults in MULTIFMT and specify LU values
greater than the ROM was configured for. So, for example, I could tell
MULTIFMT to format LU7 even though the ROM was configured for LU0-LU6!
MULTIFMT will dutifully do as you asked, but it WILL NOT change the number
of LU's that the ROM thinks is on the drive.
OK, so now let's talk about MAP. MAP is a bit similar to MULTIFMT in that
it "asks" the ROM how many LU's are on the drive. Again, the real size of
the device is not relevant, only the size that was configured into the ROM
when it was built. So, when you fire up MAP, it will (for the pre-built
ROMs) show LU0-LU6. Even if you have used MULTIFMT to create LU7, MAP will
not show it because MAP has no idea it is there. MAP is consulting with
the the ROM which still has the LUs defined as LU0-LU6. One more oddity
here... You can force MAP to map a drive to an LU beyond the number that
are configured in the ROM. MAP does not stop you from doing this (it is a
"use at your own risk" kind of thing).
The META utility is also similar. It also "asks" the ROM how many LU's
are on the device and then let's you look at that num ber of LU's. Even if
you formatted additional LU's with MULTIFMT, META will not know they are
there because the ROM has not changed.
OK, so, to recap, the ROM maintains an idea of the number of LU's on each
device which is LU0-LU6 (7 LU's) by default. The utilities will display
the number of LUs that are configured into the ROM. However, the utilities
will generally still let you manage and map LU's beyond the number
configured in the ROM.
Now, regarding Oscar's cool new image. He created his image using a
default ROM build. The image is sized for 7 LU's (0-6) and he has
populated the first 4 LU's with data. The last 3 LU's are simply empty
file systems.
When you copy his image onto a CF Card, it will put 7 LU's worth of data
in place. You could set up additional LU's after the first 7 using
MULTIFMT as you like. If you want MAP, MULTIFMT, and META to "show" more
LU's, you will need to build a custom ROM with the device capacity set for
the number of LU's that you want. You must run MULTIFMT on the added LU's
so the directories are properly formatted.
The next release of RomWBW will move the LU count information onto the
storage device itself which will greatly simplify all this. However, for
now, the thing to remember is that the ROM is configured for a set number
of LU's and believes that number no matter what you do with the utilities.
You can still force the utilities to use LU's beyond the ones the ROM
knows about, but it does not change the number of LU's that the utilities
will indicate are in existence.
Not sure if I have helped, but thought it was worth a shot...
Thanks,
Wayne
--
You received this message because you are subscribed to the Google Groups "N8VEM" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at http://groups.google.com/group/n8vem.
For more options, visit https://groups.google.com/groups/opt_out.

[Wayne Warthen]

OK, after reviewing your CPMNAME output, I see that your are booting from
the floppy drive. That is fine, but you will need to SYSGEN the updated
system image from your new ROM onto the system area of the floppy. By
booting from the floppy, you are getting the CBIOS code from there. At
present, when you update your ROM, you will need to SYSGEN the new image
onto any disks that you intend to boot from.

A quick test would be to boot directly from ROM. I think you will see the
increased number of LU's if you do that. Once you confirm that is true,
you should SYSGEN an updated system image onto any boot media you use (such
as floppy disk).

Yes, this just points out why I need to finish the work to separate the LU
count from the ROM image!

--Wayne

Post by Wayne Warthen
Thanks Bob. That is interesting. I will see if I can track that down.
--Wayne

Post by Bob Devries
Wayne, thanks for the detailed explanation.
It seems to me, however, that the utilities do *NOT* correctly get the
number of available LU's I modified my ROM code as per Douglas' suggestion,
and CPMNAME does show the CF size as 1980MB, but still only 7 LU's are
reported by META, MAP, and MULTIFMT. Methinks there's a problem somewhere...
Your suggestion that the number of available LU's be saved on the device
makes a lot of sense.
Regards, Bob Devries
Dalby, QLD, Australia
----- Original Message -----
*From:* Wayne Warthen
*Sent:* Wednesday, October 16, 2013 5:58 AM
*Subject:* Re: [N8VEM: 16275] Hard disk image for the N8VEM
Hi Bob,
I have been trying to follow this thread and I'm not sure I have been
succesful. I am thinking it might help for me to go through a little bit
of how the whole LU thing works within RomWBW. I am not sure that you are
actually having any problems.
To start with, the LU concept is implemented within CBIOS. It may be
counter-intuitive, but the number of LU's for a device (like PPIDE) is
defined in the ROM itself. This number is not specified directly, but
instead it is derived from the device capacity that is defined int he
config_ files in the build. As Douglas has mentioned, the default capacity
in the pre-built ROMs is 64MB. Based on the space required for a CP/M
drive (a bit more that 8MB), this means that by default the LU count for
all drives will be 7 (referred to as LU0 thru LU6).
So, keep in mind that no matter what size CF card you plug into your
system, the ROM will still assume there are 7 LU's (unless you change the
configuration and build a new ROM -- I will go into that in a minute).
With that said, let's talk about the utilities for a minute.
As Douglas has described, MULTIFMT will prepare your CF card to be used
by setting up the directories on the LU's. By default, MULTIFMT will "ask"
the ROM how many LU's there are. It will then suggest that you format that
number of LU's. All of this makes sense. However, you will find that you
can override the prompted defaults in MULTIFMT and specify LU values
greater than the ROM was configured for. So, for example, I could tell
MULTIFMT to format LU7 even though the ROM was configured for LU0-LU6!
MULTIFMT will dutifully do as you asked, but it WILL NOT change the number
of LU's that the ROM thinks is on the drive.
OK, so now let's talk about MAP. MAP is a bit similar to MULTIFMT in
that it "asks" the ROM how many LU's are on the drive. Again, the real
size of the device is not relevant, only the size that was configured into
the ROM when it was built. So, when you fire up MAP, it will (for the
pre-built ROMs) show LU0-LU6. Even if you have used MULTIFMT to create
LU7, MAP will not show it because MAP has no idea it is there. MAP is
consulting with the the ROM which still has the LUs defined as LU0-LU6.
One more oddity here... You can force MAP to map a drive to an LU beyond
the number that are configured in the ROM. MAP does not stop you from
doing this (it is a "use at your own risk" kind of thing).
The META utility is also similar. It also "asks" the ROM how many LU's
are on the device and then let's you look at that num ber of LU's. Even if
you formatted additional LU's with MULTIFMT, META will not know they are
there because the ROM has not changed.
OK, so, to recap, the ROM maintains an idea of the number of LU's on each
device which is LU0-LU6 (7 LU's) by default. The utilities will display
the number of LUs that are configured into the ROM. However, the utilities
will generally still let you manage and map LU's beyond the number
configured in the ROM.
Now, regarding Oscar's cool new image. He created his image using a
default ROM build. The image is sized for 7 LU's (0-6) and he has
populated the first 4 LU's with data. The last 3 LU's are simply empty
file systems.
When you copy his image onto a CF Card, it will put 7 LU's worth of data
in place. You could set up additional LU's after the first 7 using
MULTIFMT as you like. If you want MAP, MULTIFMT, and META to "show" more
LU's, you will need to build a custom ROM with the device capacity set for
the number of LU's that you want. You must run MULTIFMT on the added LU's
so the directories are properly formatted.
The next release of RomWBW will move the LU count information onto the
storage device itself which will greatly simplify all this. However, for
now, the thing to remember is that the ROM is configured for a set number
of LU's and believes that number no matter what you do with the utilities.
You can still force the utilities to use LU's beyond the ones the ROM
knows about, but it does not change the number of LU's that the utilities
will indicate are in existence.
Not sure if I have helped, but thought it was worth a shot...
Thanks,
Wayne
--
You received this message because you are subscribed to the Google Groups "N8VEM" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at http://groups.google.com/group/n8vem.
For more options, visit https://groups.google.com/groups/opt_out.

[Bob Devries]

Wayne,

Your message caused an "AHA" moment here ;)

When I boot from ROM, all seems to be well; certainly, MAP shows all 220 LU's.

Thanks for steering me right.

Regards, Bob Devries
Dalby, QLD, Australia

----- Original Message -----
From: Wayne Warthen
To: n8vem-/***@public.gmane.org
Sent: Wednesday, October 16, 2013 8:45 AM
Subject: Re: [N8VEM: 16280] Hard disk image for the N8VEM


OK, after reviewing your CPMNAME output, I see that your are booting from the floppy drive. That is fine, but you will need to SYSGEN the updated system image from your new ROM onto the system area of the floppy. By booting from the floppy, you are getting the CBIOS code from there. At present, when you update your ROM, you will need to SYSGEN the new image onto any disks that you intend to boot from.


A quick test would be to boot directly from ROM. I think you will see the increased number of LU's if you do that. Once you confirm that is true, you should SYSGEN an updated system image onto any boot media you use (such as floppy disk).


Yes, this just points out why I need to finish the work to separate the LU count from the ROM image!



--Wayne

On Tuesday, October 15, 2013 3:23:38 PM UTC-7, Wayne Warthen wrote:
Thanks Bob. That is interesting. I will see if I can track that down.


--Wayne

On Tuesday, October 15, 2013 2:48:33 PM UTC-7, Bob Devries wrote:
Wayne, thanks for the detailed explanation.

It seems to me, however, that the utilities do *NOT* correctly get the number of available LU's I modified my ROM code as per Douglas' suggestion, and CPMNAME does show the CF size as 1980MB, but still only 7 LU's are reported by META, MAP, and MULTIFMT. Methinks there's a problem somewhere...

Your suggestion that the number of available LU's be saved on the device makes a lot of sense.

Regards, Bob Devries
Dalby, QLD, Australia

----- Original Message -----
From: Wayne Warthen
To: n8...-/***@public.gmane.org
Sent: Wednesday, October 16, 2013 5:58 AM
Subject: Re: [N8VEM: 16275] Hard disk image for the N8VEM


Hi Bob,


I have been trying to follow this thread and I'm not sure I have been succesful. I am thinking it might help for me to go through a little bit of how the whole LU thing works within RomWBW. I am not sure that you are actually having any problems.


To start with, the LU concept is implemented within CBIOS. It may be counter-intuitive, but the number of LU's for a device (like PPIDE) is defined in the ROM itself. This number is not specified directly, but instead it is derived from the device capacity that is defined int he config_ files in the build. As Douglas has mentioned, the default capacity in the pre-built ROMs is 64MB. Based on the space required for a CP/M drive (a bit more that 8MB), this means that by default the LU count for all drives will be 7 (referred to as LU0 thru LU6).


So, keep in mind that no matter what size CF card you plug into your system, the ROM will still assume there are 7 LU's (unless you change the configuration and build a new ROM -- I will go into that in a minute).


With that said, let's talk about the utilities for a minute.


As Douglas has described, MULTIFMT will prepare your CF card to be used by setting up the directories on the LU's. By default, MULTIFMT will "ask" the ROM how many LU's there are. It will then suggest that you format that number of LU's. All of this makes sense. However, you will find that you can override the prompted defaults in MULTIFMT and specify LU values greater than the ROM was configured for. So, for example, I could tell MULTIFMT to format LU7 even though the ROM was configured for LU0-LU6! MULTIFMT will dutifully do as you asked, but it WILL NOT change the number of LU's that the ROM thinks is on the drive.


OK, so now let's talk about MAP. MAP is a bit similar to MULTIFMT in that it "asks" the ROM how many LU's are on the drive. Again, the real size of the device is not relevant, only the size that was configured into the ROM when it was built. So, when you fire up MAP, it will (for the pre-built ROMs) show LU0-LU6. Even if you have used MULTIFMT to create LU7, MAP will not show it because MAP has no idea it is there. MAP is consulting with the the ROM which still has the LUs defined as LU0-LU6. One more oddity here... You can force MAP to map a drive to an LU beyond the number that are configured in the ROM. MAP does not stop you from doing this (it is a "use at your own risk" kind of thing).


The META utility is also similar. It also "asks" the ROM how many LU's are on the device and then let's you look at that num ber of LU's. Even if you formatted additional LU's with MULTIFMT, META will not know they are there because the ROM has not changed.


OK, so, to recap, the ROM maintains an idea of the number of LU's on each device which is LU0-LU6 (7 LU's) by default. The utilities will display the number of LUs that are configured into the ROM. However, the utilities will generally still let you manage and map LU's beyond the number configured in the ROM.


Now, regarding Oscar's cool new image. He created his image using a default ROM build. The image is sized for 7 LU's (0-6) and he has populated the first 4 LU's with data. The last 3 LU's are simply empty file systems.


When you copy his image onto a CF Card, it will put 7 LU's worth of data in place. You could set up additional LU's after the first 7 using MULTIFMT as you like. If you want MAP, MULTIFMT, and META to "show" more LU's, you will need to build a custom ROM with the device capacity set for the number of LU's that you want. You must run MULTIFMT on the added LU's so the directories are properly formatted.


The next release of RomWBW will move the LU count information onto the storage device itself which will greatly simplify all this. However, for now, the thing to remember is that the ROM is configured for a set number of LU's and believes that number no matter what you do with the utilities. You can still force the utilities to use LU's beyond the ones the ROM knows about, but it does not change the number of LU's that the utilities will indicate are in existence.


Not sure if I have helped, but thought it was worth a shot...


Thanks,


Wayne

--
You received this message because you are subscribed to the Google Groups "N8VEM" group.
To unsubscribe from this group and stop receiving emails from it, send an email to n8vem+un...-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To post to this group, send email to n8...-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
Visit this group at http://groups.google.com/group/n8vem.
For more options, visit https://groups.google.com/groups/opt_out.


--
You received this message because you are subscribed to the Google Groups "N8VEM" group.
To unsubscribe from this group and stop receiving emails from it, send an email to n8vem+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To post to this group, send email to n8vem-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
Visit this group at http://groups.google.com/group/n8vem.
For more options, visit https://groups.google.com/groups/opt_out.

[Bob Devries]

Douglas,
The signon message in full:

[QUOTE]
ZETA Z80 @ 20MHz ROM=512KB RAM=512KB
UART0: IO=0x68 16550A BAUD=38400 FIFO
MD: UNITS=2 ROMDISK=448KB RAMDISK=416KB
FD: IO=0x36 UNITS=2
PPIDE: IO=0x60 UNITS=2

N8VEM HBIOS v2.5.1, Build 17, 25-Jun-2013
[/QUOTE]

Regards, Bob Devries
Dalby, QLD, Australia


----- Original Message -----
From: Douglas Goodall
To: n8vem-/***@public.gmane.org
Cc: Wayne Ingram
Sent: Monday, October 14, 2013 4:14 PM
Subject: Re: [N8VEM: 16263] Hard disk image for the N8VEM


Bob,


A little background…


When you are starting with a chip whose contents are unknown, you want to prepare
the chip in two respects. First there is the preparation of the directory entries which
get filled with E5's, and secondly there is a sector of metadata which includes a label
and some other stuff.


Multifmt does both, leaving you with a set of empty directories and default metadata.


After this you can copy files onto the various logical units and user numbers.


During the preparation of the .DAT file, this should have been done,


If you are using a .dat file, you should not need to format the chip in any way as all
that will be overwritten.


I don't know if the current .dat file was prepared in this way. If not the metadata might
not be there.


When you say you are not seeing the logical units you expect, are those logical units
you are looking for or user numbers?


Regards,
Douglas


On Oct 13, 2013, at 7:02 PM, Bob Devries <devries.bob-***@public.gmane.org> wrote:


Hi Douglas,

I'm having a problem using the hard disk image with my ZETA, using PPIDE. I copied the .DAT file to a 1GiB CF card, and I can access it, but I don't see all the logical units as named in the document.

I tried MULTIFMT, but it doesn't erase the CF card.

I'm using v 2.5.1 of ROMWBW; not quite the latest, but I thought it should work. Is there any special magic words I need to use? ;)

I use a PC programme called DISKIMAGE to copy the .DAT filr to the CF card. Should I format the card first?

Regards, Bob Devries
Dalby, QLD, Australia

----- Original Message -----
From: Douglas Goodall
To: n8vem-/***@public.gmane.org
Sent: Tuesday, October 08, 2013 10:24 PM
Subject: Re: [N8VEM: 16245] Hard disk image for the N8VEM


Hi Oscar,


I believe I just downloaded the dat file ok.


The default device size for SD and CF is 64MB.


7 = 64 / 9


That gives us seven logical units on a 64MB chip.


So beyond the four logical drives that are mapped by default
to LU0,LU1,LU2,LU3, the MAP command can access all seven
of the logical units.


I would use multifmt to prepare a 64MB chip, then load away.


This way you can use all of the 64MB chip, and not just the first 32MB (actually the first 36MB).




On Oct 7, 2013, at 2:56 PM, oscarv <vermeulen.oscar-***@public.gmane.org> wrote:


Hi,

Somehow I never quite got around to loading up a N8VEM hard disk image with all the classic CP/M software, and I'd expect that goes for more people.

But then I had to prepare something nice to showcase the N8VEM at the VCFe last weekend. So I finally spent a few (more than a few, in the end) hours filling a disk image. If you want, you can download this image here, and a small booklet with descriptions here. As it is for RomWBW, it'll work on SDs and CFs, on the N8VEM and the Zeta. It's certainly neither perfect nor complete, but it holds all the big languages and applications so it's a start.

BTW, the VCFe exhibit itself is described here.

Cheers,

Oscar.








--
You received this message because you are subscribed to the Google Groups "N8VEM" group.
To unsubscribe from this group and stop receiving emails from it, send an email to n8vem+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To post to this group, send email to n8vem-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
Visit this group at http://groups.google.com/group/n8vem.
For more options, visit https://groups.google.com/groups/opt_out.



---
Douglas Goodall
doug-***@public.gmane.org
http://goodall.us.com
WQRLl515




--
You received this message because you are subscribed to the Google Groups "N8VEM" group.
To unsubscribe from this group and stop receiving emails from it, send an email to n8vem+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To post to this group, send email to n8vem-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
Visit this group at http://groups.google.com/group/n8vem.
For more options, visit https://groups.google.com/groups/opt_out.



--
You received this message because you are subscribed to the Google Groups "N8VEM" group.
To unsubscribe from this group and stop receiving emails from it, send an email to n8vem+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To post to this group, send email to n8vem-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
Visit this group at http://groups.google.com/group/n8vem.
For more options, visit https://groups.google.com/groups/opt_out.


---
Douglas Goodall
doug-***@public.gmane.org
http://goodall.us.com
WQRLl515



--
You received this message because you are subscribed to the Google Groups "N8VEM" group.
To unsubscribe from this group and stop receiving emails from it, send an email to n8vem+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To post to this group, send email to n8vem-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
Visit this group at http://groups.google.com/group/n8vem.
For more options, visit https://groups.google.com/groups/opt_out.

[Wayne Warthen]

Hi Oscar,

This sounds great! I had always wanted to put together something like
this. I won't have any time until this weekend, but I will take a look and
perhaps it would be a good idea to keep this image available on the N8VEM
Wiki?

Thanks!

Wayne

Post by oscarv
Hi,
Somehow I never quite got around to loading up a N8VEM hard disk image
with all the classic CP/M software, and I'd expect that goes for more
people.
But then I had to prepare something nice to showcase the N8VEM at the VCFe
last weekend. So I finally spent a few (more than a few, in the end) hours
filling a disk image. If you want, you can download this image here<https://docs.google.com/file/d/0B_jM3_1AFMbMVS1RaXZ5eVBQNnc/edit?usp=sharing>,
and a small booklet with descriptions here<https://docs.google.com/file/d/0B_jM3_1AFMbMYUcyUUNLdjlyb28/edit?usp=sharing>.
As it is for RomWBW, it'll work on SDs and CFs, on the N8VEM and the Zeta.
It's certainly neither perfect nor complete, but it holds all the big
languages and applications so it's a start.
BTW, the VCFe exhibit itself is described here<http://obsolescenceguaranteed.blogspot.ch/2013/10/n8vem-vcfe-141-winterthur-switzerland.html>
.
Cheers,
Oscar.

[Douglas Goodall]

There are limits to the size of what you can put on the wiki, but my server
is available and has plenty of room. We can set up FTP or something.

It has Web also.

Douglas

Post by Douglas Goodall
Hi Oscar,
This sounds great! I had always wanted to put together something like this. I won't have any time until this weekend, but I will take a look and perhaps it would be a good idea to keep this image available on the N8VEM Wiki?
Thanks!
Wayne
Hi,
Somehow I never quite got around to loading up a N8VEM hard disk image with all the classic CP/M software, and I'd expect that goes for more people.
But then I had to prepare something nice to showcase the N8VEM at the VCFe last weekend. So I finally spent a few (more than a few, in the end) hours filling a disk image. If you want, you can download this image here, and a small booklet with descriptions here. As it is for RomWBW, it'll work on SDs and CFs, on the N8VEM and the Zeta. It's certainly neither perfect nor complete, but it holds all the big languages and applications so it's a start.
BTW, the VCFe exhibit itself is described here.
Cheers,
Oscar.
--
You received this message because you are subscribed to the Google Groups "N8VEM" group.
Visit this group at http://groups.google.com/group/n8vem.
For more options, visit https://groups.google.com/groups/opt_out.

---
Douglas Goodall
doug-***@public.gmane.org
http://goodall.us.com
WQRLl515

[Wayne Warthen]

Hi Oscar & Douglas,

This is a great project -- glad you are doing it. Will definitely improve
the usefulness of the N8VEM platform.

I noticed that the disk image is not compressed. Simple zip compression
reduces it's size to well below 10MB -- definitely worth compressing the
distribution files regardless of where yoiu store it for distribution.

Thanks!

Wayne

Post by Douglas Goodall
There are limits to the size of what you can put on the wiki, but my server
is available and has plenty of room. We can set up FTP or something.
It has Web also.
Douglas
Hi Oscar,
This sounds great! I had always wanted to put together something like
this. I won't have any time until this weekend, but I will take a look and
perhaps it would be a good idea to keep this image available on the N8VEM
Wiki?
Thanks!
Wayne

Post by oscarv
Hi,
Somehow I never quite got around to loading up a N8VEM hard disk image
with all the classic CP/M software, and I'd expect that goes for more
people.
But then I had to prepare something nice to showcase the N8VEM at the
VCFe last weekend. So I finally spent a few (more than a few, in the end)
hours filling a disk image. If you want, you can download this image here<https://docs.google.com/file/d/0B_jM3_1AFMbMVS1RaXZ5eVBQNnc/edit?usp=sharing>,
and a small booklet with descriptions here<https://docs.google.com/file/d/0B_jM3_1AFMbMYUcyUUNLdjlyb28/edit?usp=sharing>.
As it is for RomWBW, it'll work on SDs and CFs, on the N8VEM and the Zeta.
It's certainly neither perfect nor complete, but it holds all the big
languages and applications so it's a start.
BTW, the VCFe exhibit itself is described here<http://obsolescenceguaranteed.blogspot.ch/2013/10/n8vem-vcfe-141-winterthur-switzerland.html>
.
Cheers,
Oscar.

--
You received this message because you are subscribed to the Google Groups "N8VEM" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at http://groups.google.com/group/n8vem.
For more options, visit https://groups.google.com/groups/opt_out.
---
Douglas Goodall
http://goodall.us.com
WQRLl515

[oscarv]

Wayne,

Thanks! Actually the download image is zipped (8.6 mb), but Google Drive
shows you the inside of the zip archive prior to downloading, which is
slightly confusing.

If any desirable applications are missing, please let me know.

Regards,

Oscar.