Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Z80ASM help please
309 views
Skip to first unread message
Alan Paton
Feb 29, 2016, 5:24:18 PM2/29/16
to
Does anyone know if there is a limit to the size of files that can be assembled with Z80ASM.COM
The program that I am writing is now about 48K of assembler which compiles down to an 8K COM file. However the PRN file is 120K according to Newsweep and I am getting some strange error messages.
For instance at the end of the PRN file it says 1 error and then "AY BE FULL)"
which I understand is part of the error message (DISK MAY BE FULL)
But the disk I am using is 8160K - a compact flash drive. I have tried to assemble the file on a 1MB floppy with the same result.
I am using a 56K CPM 2.2, any advice very welcome. Thanks,Alan
The program that I am writing is now about 48K of assembler which compiles down to an 8K COM file. However the PRN file is 120K according to Newsweep and I am getting some strange error messages.
For instance at the end of the PRN file it says 1 error and then "AY BE FULL)"
which I understand is part of the error message (DISK MAY BE FULL)
But the disk I am using is 8160K - a compact flash drive. I have tried to assemble the file on a 1MB floppy with the same result.
I am using a 56K CPM 2.2, any advice very welcome. Thanks,Alan
Udo Munk
Feb 29, 2016, 5:55:37 PM2/29/16
to
Of course there is a file size limit, but not this low.
It would help to know what assembler you are using there, z80asm.com
was a common name. If this is z80asm from SLR Systems, which version?
It would help to know what assembler you are using there, z80asm.com
was a common name. If this is z80asm from SLR Systems, which version?
Ed
Mar 1, 2016, 6:19:22 AM3/1/16
to
Z80ASM isn't choking on a syntax error.
SLR asms are known to produce weird errors/messages when
memory is short. If assembling directly to a COM file, try HEX
or REL instead.
I assume you're using a late version e.g. 1.32
Alan Paton
Mar 2, 2016, 12:54:42 PM3/2/16
to
When I start the assembler the sign-on message is...
ZILOG/MOSTEK Z-80 ASSEMBLER VERSION 2.4 (1982)
I have looked through the Hex code of the assembler but cannot see SLR systems or any name.
Assuming that I am not using the SLR systems assembler, maybe that would be a better choice.
Udo Munk
Mar 2, 2016, 2:56:15 PM3/2/16
to
On Wednesday, March 2, 2016 at 6:54:42 PM UTC+1, Alan Paton wrote:
> Thanks for the replies I will try assembling to HEX
> When I start the assembler the sign-on message is...
> ZILOG/MOSTEK Z-80 ASSEMBLER VERSION 2.4 (1982)
Interesting, I would like a copy of this for the z80pack project.
> Thanks for the replies I will try assembling to HEX
> When I start the assembler the sign-on message is...
> ZILOG/MOSTEK Z-80 ASSEMBLER VERSION 2.4 (1982)
In the 80th I used development systems from Zilog and Mostek sometimes,
most work was done with the Mostek cross development tools on UNIX
systems. But if I remember right these boxes weren't running CP/M, but
more or less CP/M compatible OS's from Zilog and Mostek. So your
problem might be related to some CP/M incompatibility.
> I have looked through the Hex code of the assembler but cannot see
> SLR systems or any name.
> Assuming that I am not using the SLR systems assembler, maybe that
> would be a better choice.
Z80 ASSEMBLER Copyright (C) 1983 by SLR Systems Rel. 1.30 #F10268
This one is most compatible to the Zilog and Mostek assemblers,
so chances are good that sources assemble without too much changes.
Later versions of the SLR assemblers cause more problems than I'm
willing to tolerate for my stuff.
Floppy Software
Mar 2, 2016, 3:09:06 PM3/2/16
to
You are using a PD assembler also known as Z80ASMUK or ZSM.
It's my assembler of choice, I use it to assemble the MESCC compiler output, and its source code is available.
You can download an improved version (v2.8) from my website:
www.floppysoftware.es
It's my assembler of choice, I use it to assemble the MESCC compiler output, and its source code is available.
You can download an improved version (v2.8) from my website:
www.floppysoftware.es
Ed
Mar 2, 2016, 7:39:58 PM3/2/16
to
Udo Munk wrote:
> ...
to version 1.32. Introducing bugs into an existing program is something
I'm guilty of too and it can take a version or two before it's noticed.
It's a pity SLR didn't stay around long enough to quash theirs.
> ...
> I would suggest to use this version:
>
> Z80 ASSEMBLER Copyright (C) 1983 by SLR Systems Rel. 1.30 #F10268
> ...
>
> Z80 ASSEMBLER Copyright (C) 1983 by SLR Systems Rel. 1.30 #F10268
> Later versions of the SLR assemblers cause more problems than I'm
> willing to tolerate for my stuff.
Thanks for the tip. By the time I'd purchased Z80ASM was already up
> willing to tolerate for my stuff.
to version 1.32. Introducing bugs into an existing program is something
I'm guilty of too and it can take a version or two before it's noticed.
It's a pity SLR didn't stay around long enough to quash theirs.
Alan Paton
Mar 4, 2016, 5:24:56 AM3/4/16
to
On Monday, February 29, 2016 at 10:24:18 PM UTC, Alan Paton wrote:
Firstly thanks for the link to ZSM assembler Version 2.8. It is much improved to the previous version which I have been using for some years.
I had been using the assembler to write some software which has grown larger than my usual programs. Over a number of weeks I had been making regular backups as it developed but recently some strange errors were occurring. At first I assumed it was the code at fault then I thought it was the assembler corrupting the code.
But I have found that it is NewSweep and PIP that both corrupt the data when it becomes about 30K or more.
I have made some 40K test files with just a single ascii character so that they can be easily checked. And when they are copied using either PIP or NewSweep they become corrupt at about 7900H to 807FH - therefore when making a backup of a good file a corrupt one is produced which has been making programming quite a challenge.
I am using a compact flash drive which is partitioned into 14 x 8MB drives C: to P:
After further testing I have found that if I have PIP or NewSweep installed on a Floppy drive (B:) I can copy any large file to or from any disk without error.
So somehow PIP and NewSweep will only work with data no larger than about 30K when installed on large drives.
I hope this information will help others to avoid this type of problem in the future.
Is there a better way make back-up files when developing software?
Have there been any updates to avoid this?
I am using CP/M 2.2 and possibly this would not occur with CP/M 3 or other versions.
John Garza
Mar 4, 2016, 7:13:14 AM3/4/16
to
could be at fault. I've moved 100K+ files across my vintage CP/M hard
drives with no problem.
My setup is very different. I still write code for my CP/M systems, but
I don't use CP/M for development. I use 22disk which emulates CP/M on
DOS, and I run that under DOSbox on Ubuntu. The net result is that all
the development files are readily available under the native Linux
operating system and can be backed up normally, as well as
edited/debugged with better/faster tools. When the code checks out OK,
I use XMODEM to send it over to a CP/M machine.
For everyday running, I use Minicom in Linux to connect to a CP/M
machine. So one of the windows on my Ubuntu desktop is actually a
'terminal' into CP/M running on an IMSAI sitting next to my desk.
-John
Steven Hirsch
Mar 4, 2016, 7:37:01 AM3/4/16
to
On 03/04/2016 05:24 AM, Alan Paton wrote:
> I am using a compact flash drive which is partitioned into 14 x 8MB drives
> C: to P: After further testing I have found that if I have PIP or NewSweep
> installed on a Floppy drive (B:) I can copy any large file to or from any
> disk without error. So somehow PIP and NewSweep will only work with data no
> larger than about 30K when installed on large drives.
>
> I hope this information will help others to avoid this type of problem in
> the future.
What hardware are you running on? It sounds like you have some low-level
> I am using a compact flash drive which is partitioned into 14 x 8MB drives
> C: to P: After further testing I have found that if I have PIP or NewSweep
> installed on a Floppy drive (B:) I can copy any large file to or from any
> disk without error. So somehow PIP and NewSweep will only work with data no
> larger than about 30K when installed on large drives.
>
> I hope this information will help others to avoid this type of problem in
> the future.
problems on that system. I've been copying CP/M files (small to very large)
using PIP, nsweep, you-name-it for 35 years and have never seen what you're
describing.
Alan Paton
Mar 4, 2016, 12:32:45 PM3/4/16
to
On Friday, March 4, 2016 at 12:13:14 PM UTC, John Garza wrote:
>
>
>
> Very interesting problem. Sounds like the CF drive and/or it's firmware
> could be at fault. I've moved 100K+ files across my vintage CP/M hard
> drives with no problem.
>
> My setup is very different. I still write code for my CP/M systems, but
> I don't use CP/M for development. I use 22disk which emulates CP/M on
> DOS, and I run that under DOSbox on Ubuntu. The net result is that all
> the development files are readily available under the native Linux
> operating system and can be backed up normally, as well as
> edited/debugged with better/faster tools. When the code checks out OK,
> I use XMODEM to send it over to a CP/M machine.
>
> For everyday running, I use Minicom in Linux to connect to a CP/M
> machine. So one of the windows on my Ubuntu desktop is actually a
> 'terminal' into CP/M running on an IMSAI sitting next to my desk.
>
>
> -John
Thanks John, Yes I would like to develop CP/M programs on a PC but the system I am using is an Interak (1982) which has a memory mapped display and programmable graphics. Most of my programs use this feature so I have to work with the machine.
>
>
>
> Very interesting problem. Sounds like the CF drive and/or it's firmware
> could be at fault. I've moved 100K+ files across my vintage CP/M hard
> drives with no problem.
>
> My setup is very different. I still write code for my CP/M systems, but
> I don't use CP/M for development. I use 22disk which emulates CP/M on
> DOS, and I run that under DOSbox on Ubuntu. The net result is that all
> the development files are readily available under the native Linux
> operating system and can be backed up normally, as well as
> edited/debugged with better/faster tools. When the code checks out OK,
> I use XMODEM to send it over to a CP/M machine.
>
> For everyday running, I use Minicom in Linux to connect to a CP/M
> machine. So one of the windows on my Ubuntu desktop is actually a
> 'terminal' into CP/M running on an IMSAI sitting next to my desk.
>
>
> -John
Are your hard drives 8MB or more? And are you moving files from CP/M drive to CP/M drive - if so then PIP and NewSweep must be OK for this.
I am not ruling out a problem with my CF firmware - What kind of problem would cause this?
I have been using the CF drive since 2006 and have not noticed a problem until my assembler files became large.
One test that I tried was formatting 2 of the drives and checking the directory area with DU to make sure there were E5's everywhere. Then transferred the large PRN file from one to the other. Checking the directory again I could see the file in there and the entry appeared OK but when displaying on-screen with the TYPE command a chunk of it was corrupt.
.Alan
Floppy Software
Mar 4, 2016, 12:37:41 PM3/4/16
to
El viernes, 4 de marzo de 2016, 13:13:14 (UTC+1), John Garza escribió:
> On 03/04/2016 04:24 AM, Alan Paton wrote:
> > But I have found that it is NewSweep and PIP that both corrupt the data when it becomes about 30K or more.
That sounds like a BIOS or firmware bug, not related to PIP or CP/M.
> On 03/04/2016 04:24 AM, Alan Paton wrote:
> > But I have found that it is NewSweep and PIP that both corrupt the data when it becomes about 30K or more.
If the problem does not appears with your floppy drives, look for a bug in the BIOS section of your compact flash drive.
Are the DPH & DPB correctly defined?
John Garza
Mar 4, 2016, 1:35:54 PM3/4/16
to
I also have some specialized hardware on the CP/M machines (cassette
tape interface, Dazzler, etc.) But I still DEVELOP on a PC and EXECUTE
on the CP/M machines. You will be amazed at how much faster development
proceeds.
I have multiple logical drives all a tad under 8M (8100K or so each). I
seem to recall a limit on disk size in CP/M. Maybe you are at the limit
if you are 8192K or above.
Also, try using object-mode and verify options on PIP, [OV]
-John
John Garza
Mar 4, 2016, 1:47:34 PM3/4/16
to
comes to 8M. So likely a design limitation based on 16 bit indices. I
think CPM 3 managed to get around this though.
-John
Udo Munk
Mar 4, 2016, 1:59:15 PM3/4/16
to
On Friday, March 4, 2016 at 7:47:34 PM UTC+1, John Garza wrote:
> BTW, CPM 2.2 has a 128 byte record size. And 65535 of those records
> comes to 8M. So likely a design limitation based on 16 bit indices. I
> think CPM 3 managed to get around this though.
Correct, CP/M 3 and MP/M support drives with 512MB and it's working.
> BTW, CPM 2.2 has a 128 byte record size. And 65535 of those records
> comes to 8M. So likely a design limitation based on 16 bit indices. I
> think CPM 3 managed to get around this though.
And if you connect a disk > 8MB to CP/M 2.2 it just uses the first 8MB
and the rest is unused, because it can't be addressed.
Alan Paton
Mar 4, 2016, 2:02:36 PM3/4/16
to
each of the 8MB drives is defined as
HD8MBx:DEFW 0000
DEFW 0000
DEFB 00,00,00,00
DEFW DIRBUF
DEFW DPBHD
DEFW CSV0 to F) ;
DEFW ALV0 to F) ;defs 128
where DIRBUF is defs 128 bytes (the same DIRBUF for each drive)~?
DPBHD is
DPBHD:defw 128 ;32 SPT x4 CPM sectors
defb 6 ;BSH
HDBLM:defb 63 ;BLM
defb 3 ;extent mask
defw 3FFH ;DSM
defw 3FFH ;max dir entries -1
defb 0F0H ;4 blocks dir
defb 00
defb 0 ;no scratch
defw 2 ;2 tracks offset
I am definitely not 100% about this
also I left the sector shift at 2 and the sector mask at 3 - as he suggested for a Conner hard drive.
Hope the above is OK - Alan
Steven Hirsch
Mar 4, 2016, 5:20:32 PM3/4/16
to
the top of my head what the limit is, but I don't think it's anywhere near 512MB.
Floppy Software
Mar 4, 2016, 5:49:53 PM3/4/16
to
ldkr...@gmail.com
Mar 4, 2016, 6:44:29 PM3/4/16
to
John Garza,
[quote]
Don't you really mean 22NICE (Insystem CP/M 2.2 Emulator) versus 22DISK?
Larry
[quote]
I use 22disk which emulates CP/M on
DOS, and I run that under DOSbox on Ubuntu.
[/quote]
DOS, and I run that under DOSbox on Ubuntu.
Don't you really mean 22NICE (Insystem CP/M 2.2 Emulator) versus 22DISK?
Larry
Ed
Mar 4, 2016, 7:18:51 PM3/4/16
to
65536 * 128 * 4. Drive capacity depended on the data block size.
John Garza
Mar 5, 2016, 9:04:58 AM3/5/16
to
-J
Alan Paton
Mar 5, 2016, 10:01:02 AM3/5/16
to
On Friday, March 4, 2016 at 10:49:53 PM UTC, Floppy Software wrote:
> El viernes, 4 de marzo de 2016, 20:02:36 (UTC+1), Alan Paton escribió:
>
>
> What about the SECTRAN function in the BIOS?
Thanks for the advice I have received from this group.
> El viernes, 4 de marzo de 2016, 20:02:36 (UTC+1), Alan Paton escribió:
>
>
> What about the SECTRAN function in the BIOS?
As far as I can tell I do not seem to have a sector translation table I think that the value in BC is transferred to HL when reading or writing to disk.
The file corruption is beginning to look like a bios problem. The corrupt data within the file is exactly 128 bytes - size of the disk buffer.
But why isn't every file corrupt?
Result when typing STAT D:DSK:
. D: Drive Characteristics
.65536: 128 Byte Record Capacity
. 8192: Kilobyte Drive Capacity
. 1024: 32 Byte Directory Entries
. 512: Records/Extent
. 64: Records/Block
. 128: Sectors/Track
. 2: Reserved Tracks
Is this normal data for a CF Drive? Has anyone else got a CF drive set-up like this?
Surely I can't be the only person on this group using a CF drive;~(
.Alan
Udo Munk
Mar 5, 2016, 10:47:32 AM3/5/16
to
Here a proofed 4MB HD from z80pack. You can try this to see if your
problem is BIOS related.
;
; fixed data tables for 4MB harddisks
;
; disk parameter header
HDB1: DEFW 0000H,0000H
DEFW 0000H,0000H
DEFW DIRBF,HDBLK
DEFW CHKHD1,ALLHD1
HDB2: DEFW 0000H,0000H
DEFW 0000H,0000H
DEFW DIRBF,HDBLK
DEFW CHKHD2,ALLHD2
;
; disk parameter block for harddisk
;
HDBLK: DEFW 128 ;sectors per track
DEFB 4 ;block shift factor
DEFB 15 ;block mask
DEFB 0 ;extent mask
DEFW 2039 ;disk size-1
DEFW 1023 ;directory max
DEFB 255 ;alloc 0
DEFB 255 ;alloc 1
DEFW 0 ;check size
DEFW 0 ;track offset
DIRBF: DEFS 128 ;scratch directory area
ALLHD1: DEFS 255 ;allocation vector harddisk 1
ALLHD2: DEFS 255 ;allocation vector harddisk 2
CHKHD1: DEFS 0 ;check vector harddisk 1
CHKHD2: DEFS 0 ;check vector harddisk 2
If that works something is wrong with your 8MB disk definitions.
problem is BIOS related.
;
; fixed data tables for 4MB harddisks
;
; disk parameter header
HDB1: DEFW 0000H,0000H
DEFW 0000H,0000H
DEFW DIRBF,HDBLK
DEFW CHKHD1,ALLHD1
HDB2: DEFW 0000H,0000H
DEFW 0000H,0000H
DEFW DIRBF,HDBLK
DEFW CHKHD2,ALLHD2
;
; disk parameter block for harddisk
;
HDBLK: DEFW 128 ;sectors per track
DEFB 4 ;block shift factor
DEFB 15 ;block mask
DEFB 0 ;extent mask
DEFW 2039 ;disk size-1
DEFW 1023 ;directory max
DEFB 255 ;alloc 0
DEFB 255 ;alloc 1
DEFW 0 ;check size
DEFW 0 ;track offset
DIRBF: DEFS 128 ;scratch directory area
ALLHD1: DEFS 255 ;allocation vector harddisk 1
ALLHD2: DEFS 255 ;allocation vector harddisk 2
CHKHD1: DEFS 0 ;check vector harddisk 1
CHKHD2: DEFS 0 ;check vector harddisk 2
If that works something is wrong with your 8MB disk definitions.
Alan Paton
Mar 5, 2016, 11:41:07 AM3/5/16
to
.Alan
Floppy Software
Mar 5, 2016, 12:42:41 PM3/5/16
to
Is your DPB 14 bytes long as posted by you?
Because it must be 15 bytes long, as posted by Udo.
The field for the scratch area must to be a word, no a byte.
Because it must be 15 bytes long, as posted by Udo.
The field for the scratch area must to be a word, no a byte.
Jack Strangio
Mar 5, 2016, 6:57:30 PM3/5/16
to
Udo Munk <udo....@freenet.de> writes:
> And if you connect a disk > 8MB to CP/M 2.2 it just uses the first 8MB
> and the rest is unused, because it can't be addressed.
Not necessarily. There is a CP/M-drive size limit of 8MB. But it is possible
> And if you connect a disk > 8MB to CP/M 2.2 it just uses the first 8MB
> and the rest is unused, because it can't be addressed.
to use larger hard disks containing more than one CP/M-drive. I have a BDOS
which uses 32 MB hard-drives and each holds 4x 8MB CP/M-drives.
Jack
--
"It's rather cold." she said bitchily.
Udo Munk
Mar 6, 2016, 2:13:48 AM3/6/16
to
On Sunday, March 6, 2016 at 12:57:30 AM UTC+1, Jack Strangio wrote:
> Udo Munk <udo....@freenet.de> writes:
> > And if you connect a disk > 8MB to CP/M 2.2 it just uses the first 8MB
> > and the rest is unused, because it can't be addressed.
>
>
> Not necessarily. There is a CP/M-drive size limit of 8MB. But it is possible
> to use larger hard disks containing more than one CP/M-drive. I have a BDOS
> which uses 32 MB hard-drives and each holds 4x 8MB CP/M-drives.
Of course one can partition disks and present each partition as a disk drive
> Udo Munk <udo....@freenet.de> writes:
> > And if you connect a disk > 8MB to CP/M 2.2 it just uses the first 8MB
> > and the rest is unused, because it can't be addressed.
>
>
> Not necessarily. There is a CP/M-drive size limit of 8MB. But it is possible
> to use larger hard disks containing more than one CP/M-drive. I have a BDOS
> which uses 32 MB hard-drives and each holds 4x 8MB CP/M-drives.
to an operating system, so that everything stays within the technical limits.
Otherwise the reminder of a disk too large can't be addressed.
Alan Paton
Mar 6, 2016, 7:12:44 AM3/6/16
to
I will re-arrange my CF drive. Udo is using 4MB partitions which I think is much better. I mean who wants 8MB of CP/M files on 1 disk? If you typed DIR you could have a long wait. (non-commercial use)
It will take me a while to sort this problem as my BIOS is in EPROM and gets loaded at power-on. Also the CF drive is a fixed module (IDE DOM) so I cannot change it as easily as unplugging a CF card.
I got the IDE DOM because I heard that they were more reliable than a CF card with IDE adapter. But now maybe I will change that.
.Alan
0 new messages