I have coded up XMOVE using DMA and it is running. I still use GENCPM to take care of HASH, ALV, DIRBCB and DTABCB. I now ran into the same problem Tony has, i.e., when pip large file (help.hlp is my test file), it can't verify. However, I can pip small files without any issue. The one GENCPM option that seems to solve the problem is answering 'N' to the question 'Allocate buffers outside of Common (Y) ?'. I set up the disks with different combination of directory buffers, data buffers, and allocate buffers outside of common. Only the disks that have outside allocated buffers failed write verify. I'm using 3 banks of memory.

PS, I'm going to port the same software (slightly modified) to Z280 running in 8-bit Z80-compatible bus (https://github.com/Plasmode/ZZ80RC and see if it has the same problem.

All this has fixed the Banked version that uses just bank 0 and 1 - see below (except for CP/M 3 PIP's verify error). The multi-bank version is still not working though.

I remember running into a similar problem when I was first developing a banked CP/M 3 BIOS for my P112: PIP corrupted files larger than a certain size during copy, and very large programs (e.g. HiTech C compiler) used to crash unexpectedly.

The problem had to do with the fact that in CP/M 3 the TPA extends above the application bank partially into the common area (unlike e.g. MP/M). Since the application bank is normally on bank 1 and the common area on bank 0, that means that the TPA is not contiguous in physical memory.

PIP apparently uses all the available memory as copy buffer, and when copying large files a file sector will land sooner or later within the crossing area between the two banks. Since the Z180 DMA can transfer data between physical addresses only, it could not copy such a sector correctly.

Since your BIOS is using DMA transfers, I suspect you may be running into the same problem.

One solution is to check for that particular case and then do two DMA transfers (the Z280 can chain two DMA channels for that purpose). A simpler (but slower) fix is to do a byte-by-byte copy from one bank to another (the Z280 ldup instruction will become handy here).

agn453 wrote on Sun, 11 November 2018 21:49

All this has fixed the Banked version that uses just bank 0 and 1 - see below (except for CP/M 3 PIP's verify error). The multi-bank version is still not working though.

I remember running into a similar problem when I was first developing a banked CP/M 3 BIOS for my P112: PIP corrupted files larger than a certain size during copy, and very large programs (e.g. HiTech C compiler) used to crash unexpectedly.

The problem had to do with the fact that in CP/M 3 the TPA extends above the application bank partially into the common area (unlike e.g. MP/M). Since the application bank is normally on bank 1 and the common area on bank 0, that means that the TPA is not contiguous in physical memory.

PIP apparently uses all the available memory as copy buffer, and when copying large files a file sector will land sooner or later within the crossing area between the two banks. Since the Z180 DMA can transfer data between physical addresses only, it could not copy such a sector correctly.

Since your BIOS is using DMA transfers, I suspect you may be running into the same problem.

One solution is to check for that particular case and then do two DMA transfers (the Z280 can chain two DMA channels for that purpose). A simpler (but slower) fix is to do a byte-by-byte copy from one bank to another (the Z280 ldup instruction will become handy here).

That's a great explanation to why PIP with verify of small files works, but not large files.

I do check the source & destination addresses of xmove to make sure it is not in the common memory. In fact that was the fix that solved the PIP-with-verify error. But do I need to check whether a single xmove call can have address started in banked memory but finished in the common memory?
Bill

Tony,
It seems to work well except xmodem is not working. It will start up and waiting for data but will not start data transfer. The hardware will hang, some of the time (ctrl C does not get hardware's attention). Otherwise it runs MBASIC80 (StarTrek works! and Zork. I even commented out OUTJMP and reassembled it and it works the same.
Bill

Tony, just installed your banked BIOS on my Z280RC and so far is working perfectly!

The XMODEM problem is again the serial port speed, which was already on the edge. Very likely the new conin BIOS routine has an extra overhead which causes the next character to be missed. If the serial speed is lowered, or if the sending application on the PC side adds a small per-character delay, then the transfer will succeed.

..snip..
The hardware will hang, some of the time (ctrl C does not get hardware's attention).
..snip.
Bill

Tony,
I simplified your conin routine to check out the timing issue associated with XMODEM.

conin:
; console char into reg A
	in a,(RxStat)	;;; read on-chip UART receiver status
	and 10h		; data available?
	jp z,conin
	in a,(RxData)	; get it in Reg A
	ret

XMODEM works with the simplified console input (this is the same routine in my CPM2.2) and I have experimentally verified that I can insert up to 15 NOP and it still works, but failed with 20 NOPs. That's not very much time to do anything significant in the conin routine.

This is useful because it checks out your CP/M3 implementation is good, that XMODEM failed only because of the console input delay, not because of other potential CP/M3 bugs.

..snip..

XM filename,ext /S      will send a file from the Z280RC system,

or

XM filename.ext /R      will receive a file to the Z280RC system.

XM filename.ext /S/X3/Z9

The Z280 UART is designed to be driven via a DMA channel. So you don't need to breadboard up a new UART so much as fix up the CP/M BIOS to use the DMA functionality at least on receive.

On another matter - last night I was trying to compile the source-code for Simeon Cran's ZPM3 BDOS with your ZSM4 beta 10. It throws up some M and D errors (long symbol names) that M80 doesn't. Perhaps you'd like to take a look at it. Probably it's too much work to make ZSM4 handle longer symbols - but you'd know best!

etchedpixels wrote on Wed, 14 November 2018 06:47

The Z280 UART is designed to be driven via a DMA channel. So you don't need to breadboard up a new UART so much as fix up the CP/M BIOS to use the DMA functionality at least on receive.

Not enough. With the BIOS overhead, fetching a char from the DMA buffer will take nearly as many CPU cycles as fetching it from an I/O port. Thus, when receiving a large block of data the buffer can overflow anyway before XMODEM has time to collect all bytes.

Yes, one can optimize the DMA buffer size for XMODEM's particular case, but sooner or later you'll come across an application that needs that additional byte...

Alan, my point is that not everything is X/Y/Z modem. And that DMA alone is a brute-force approach, and as such there are many situations where it will simply fail. If you want things to work reliably at whatever speed over a RS232 link, then you need hardware handshake lines.

hperaza wrote on Wed, 14 November 2018 10:01

Alan, my point is that not everything is X/Y/Z modem. And that DMA alone is a brute-force approach, and as such there are many situations where it will simply fail. If you want things to work reliably at whatever speed over a RS232 link, then you need hardware handshake lines.

I'm at this point just going to politely disagree with you and point out the internet doesn't use hardware flow control either.

I just uploaded a new version (beta 11) that increases the max identifier length to 15 chars, and that's the maximum it can handle without changing the symbol table structure. It appears to assemble the ZPM3 BDOS correctly now.

Tony,
Thank you! XM27Z280 works great on your CP/M3. XMODEM is my most used tool, I wouldn't know what to do if it doesn't work. Just as importantly, I read your comments about using XIZ, wow, what a time saver!
Bill

Hector had raised a couple issues with the Z280RC and they are actually interconnected. The CF byteswap issue due to hardware design error can be fixed with software with about 5% performance penalty.

Tony,
I have not thought too much about rev 2 of Z280RC. I like to have reasonable solutions for the existing concerns such as UART receive DMA as well as the inability to handle Mode 2 interrupt acknowledge. A forum member, I forgot whom, pointed out Tilmann Reh's solution which I thought was very clever and at the same time fix the problem of DS1302 RTC not being accurate.

I do have a software byteswap fix that I can post on my GitHub page as an alternative for people wanting to transfer files via moving the physical CF card between PC and Z280RC. I did a disk copy benchmark and which measured 39 seconds instead of 37 seconds without software byte swap--about 5% degradation which is smaller than speed variations among different brand of CF disks. It is a simple algorithm, but affect ZZMon and CP/M and all existing data. Another word, the CF disk needs to be initialized and loaded with new set of software and files.

My original directory setting and number and size of drives were arbitrary, which is rather frightening because I have had no prior CP/M experience! With CP/M3 it is a good time to change the directory entries and number of disk drives. My smallest CF disk is 64Meg, so we can have eight 8-meg drives and more directory entries. How do you initialize each drive?
Bill

CP/M V3.0 Loader
Copyright (C) 1998, Caldera Inc.

 RESBIOS3 SPR  F700  0900
 BNKBIOS3 SPR  BD00  2300
 RESBDOS3 SPR  F100  0600
 BNKBDOS3 SPR  8F00  2E00

 60K TPA

Z280RC Banked BIOS 15-Nov-2018
Built with Cache MOVE-w/MMU BigDirE-H Cont.-DMA Alloc-CSV
Drives CompactFlash A:..H: RamDisk M:

..snip..

C>show e:[dr
D:SHOW     COM

        E: Drive Characteristics
   64,512: 128 Byte Record Capacity
    8,064: Kilobyte Drive  Capacity
    1,024: 32 Byte  Directory Entries
        0: Checked  Directory Entries
      256: Records / Directory Entry
       32: Records / Block
    1,024: Records / Track
      256: Reserved  Tracks
      512: Bytes / Physical Record


C>du
A:DU       COM

DISK UTILITY v8.8
Universal Version under CP/M 3.1

Type ? for help
Type X to exit

:le					<- Login drive E

:g0					<- Read Group 0
G=0000:00, T=256, S=1, PS=0

:ch0-7f,e5;w;+;/256			<- Change whole sector to E5, Write,
						 Next Sector, Repeat 256 times

0000000000000000F10000000B07FEFFFEFFFFFF00000000000000000000000000020100000B09FE
FFFEFFFFFF00000000000000000000000000130100000B0BFEFFFEFFFFFF00000000000000000000
000000240100000B0DFEFFFEFFFFFF000004051F01BF07FF01F0000000010002030004051F01DF07
FF01F00000004000G=0000:01, T=256, S=2, PS=0
02030004051F01DF07FF01F0000000800002030004051F01DF07FF01F0000000C00002030004051F
017F03FF01F00000000001020363007C009500AE00C7000000000000000000000000000000000000
0000000000310001CD08043EE2D3103E80D312D314AF320300320400213F04CD1E04310001210300
2201002A62FE2206G=0000:02, T=256, S=3, PS=0
003EC33200003205000624215C00CDBF03215C00360123119A04010B00CD6502115C000E0FCD0500
3CCAD201110001D50E1ACD0500115C000E14CD0500B7D1C2CA0121800019EBC3AF01FE01C2DB01C3
000121A504CD1E04C3010221C104CD1E04C301020E09CD05000E01CD0500C372010E34C3F8010E39
CD1502213504CD1EG=0000:03, T=256, S=4, PS=0
0418FEDB14E610C83EFFC9DB14E610CA0B02DB16C9DB12E601CA150279D318C93EFFC9AFC9210000
79FE05D032E404216300FE00C8217C00FE01C8219500FE02C821AE00FE03C821C700C9010000ED43
E504C9ED43E704C96069C9696022E904C9213501C9EBEDB0EBC93AE404FE04CAAE02E5C5CD13043E
40D3CD3AE704D3C7G=0000:04, T=256, S=5, PS=1

..snip..

:g0
G=0000:00, T=256, S=1, PS=0

:d
00  E5E5E5E5 E5E5E5E5  E5E5E5E5 E5E5E5E5  *eeeeeeeeeeeeeeee*
10  E5E5E5E5 E5E5E5E5  E5E5E5E5 E5E5E5E5  *eeeeeeeeeeeeeeee*
20  E5E5E5E5 E5E5E5E5  E5E5E5E5 E5E5E5E5  *eeeeeeeeeeeeeeee*
30  E5E5E5E5 E5E5E5E5  E5E5E5E5 E5E5E5E5  *eeeeeeeeeeeeeeee*
40  E5E5E5E5 E5E5E5E5  E5E5E5E5 E5E5E5E5  *eeeeeeeeeeeeeeee*
50  E5E5E5E5 E5E5E5E5  E5E5E5E5 E5E5E5E5  *eeeeeeeeeeeeeeee*
60  E5E5E5E5 E5E5E5E5  E5E5E5E5 E5E5E5E5  *eeeeeeeeeeeeeeee*
70  E5E5E5E5 E5E5E5E5  E5E5E5E5 E5E5E5E5  *eeeeeeeeeeeeeeee*

:x

C>initdir e:
A:INITDIR  COM


INITDIR WILL ACTIVATE TIME STAMPS FOR SPECIFIED DRIVE.
Do you want to re-format the directory on drive: E  (Y/N)?  y

C>set e: [name=ide0.p04,create=on,update=on
D:SET      COM

Label for drive E:

Directory       Passwds  Stamp    Stamp    Stamp
Label           Reqd     Create   Access   Update
--------------  -------  -------  -------  -------
E:IDE0    .P04    off      on       off      on


C>show e:[dr,lab
D:SHOW     COM

Label for drive E:

Directory     Passwds  Stamp   Stamp
Label         Reqd     Create  Update  Label Created   Label Updated
------------  -------  ------  ------  --------------  --------------
IDE0    .P04    off     on      on     15/11/18 14:20  15/11/18 14:20

        E: Drive Characteristics
   64,512: 128 Byte Record Capacity
    8,064: Kilobyte Drive  Capacity
    1,024: 32 Byte  Directory Entries
        0: Checked  Directory Entries
      256: Records / Directory Entry
       32: Records / Block
    1,024: Records / Track
      256: Reserved  Tracks
      512: Bytes / Physical Record


C>

Also, I've hit the 512 directory entries limit on the CompactFlash 8MB drives a few times (particularly with timestamps enabled). I'm considering increasing it to 1024 for the optional drives E:..H: that can be configured in my BIOS.

...
I've been tempted to disassemble ZTRANS.COM to make it output lower case... but I've been xmodem'ng up to host (macOS) and then using bbedit to convert to lower case and then xmodem'ng back down to the target (z280rc) machine.

I'd go directly for 4096 directory entries - once you start copying files, assembling and/or compiling applications you will hit the 1024-entry limit very quickly
..snip..