plasmo wrote on Fri, 07 September 2018 18:49

Why can Z280RC handles 132 data packet from PC but not the same data packet from Linux machine is puzzling.

Just did a quick test: switched the terminal program to use 2 stop bits (8O2) instead of 1, and XMODEM now works without having to insert any additional inter-character delays. Back to 1 stop bit and all I get is a bunch of "Retry 0: NAK on sector" as before. I guess that 115200 is just at the edge of what XMODEM+CP/M can handle. Minor variations of the clock frequency could explain why it works with your PC but not with mine.

With all this discussion about data rates, I'm going to be a bit of a devil's advocate. The default speed I use on my Z180's is 115,200 to/from Win7/HyperTerm and I've never had an issue. That got me thinking about how fast a very basic 4MHz Z80 could handle XMODEM data. My conclusion is that 115,200 should NOT be a problem nor should 230,400. The 10MHz SIO should support 115,200 and I'd have to look at other UARTs for 230,400. The only assumption is that the UART has both a data register and a receive register i.e. additonal data can be received while valid data is still pending a read.

The real key is the software. While the original XMODEM certainly works it is *FAR* from optimized code with a subroutine call and extra logic PER BYTE. By definition, the XMODEM protocol has a built-in handshake to limit data flow and the sender should not be sending any additional data after a packet until it receives an ACK or NAK. The only real timing issue is with the receipt of a 132 byte packet.

The following snippet shows how a 4MHz Z80 can get a serial data byte in 15.5uS or 23us if the status check just misses the change and causes an extra loop. By my calculation, that equates to 43,478 Bytes/sec worst case. At 8,N,1 that's 434,782 baud!

Perhaps someone can show me why my theoretical calculations are wrong.

Version 2.6 is a pretty significant rewrite, focused on speeding up transfers. By far the biggest speedup came from changing the CRC calculation to a table-driven algorithm. But I also flattened the code a bit, eliminating several layers of subroutine calls, as well as a few other speed enhancements. The resulting code can now send and receive at 76.8K baud with a 2 MHz 8080. It can theoretically go twice as fast with a 4 MHz Z80. However, I was only able to test it at 115.2K baud on my 4 MHz Z80 machine, since this is the maximum baud rate for the Z80-DART. (Still this is more than 3 times as fast as version 2.5!)

I don't use this code myself as the 33MHz Z8S180 is fine with extra overhead at 115,200 and has a four byte buffer. After the various comments this was just a quick-n-dirty curiosity wander to see what the maximum XMODEM baud rate on a 4 MHz Z80 MIGHT be and whether 115,200 could be supported.

Through the years I've seen a LOT of inefficient code and lots of bloat that lead people to believe there are hardware limitations when in fact it's software.

For the TRS-80 case specifically, the limits had as much to do with the IRQ setup in that hardware as anything else. That and floppy I/O, which was NMI driven programmed I/O. For direct text to the screen, the frame buffer was memory mapped and required software scrolling and remapping. Oh, and the software-scanned keyboard, with timer IRQ driven typeahead....

For next experiment, I kludged in a 1.84MHz clock to the UART so I can change the CPU clock without affecting the serial baud clock. I lower the CPU clock from 29.5MHz to 24MHz and I still can transfer data with XMODEM without any problem. So I don't think Z280RC is barely fast enough to run XMODEM at 29.5MHz.

There is something different about XMODEM on Linux but 2 stops may be an interim fix.

1. CF byte-swap is still a problem although if XMODEM transfer at 115200 can be reliably achieved, the need of moving CF disk back and forth between PC & Z280RC may not be so pressing. In view of the number of existing Z280RC hardware out there, I want to find a software solution. I'm still thinking about byte swapping in Z280 software or use CF interface in 8-bit mode and enable DMA to make up for the lost performance.

2. The discussion on UART hardware handshakes are instructive. Initially I thought about bring out two discrete I/O from CPLD as hardware handshakes, but they are interrupt driven and if the lower priority console task is preempted by higher priority task, the interrupt driven hardware handshake won't work. Since I do have 256K of uncommitted memory, I'll pin my hope on massive size DMA buffers base on the argument that if 64K of DMA buffers are still not sufficient, perhaps the problem is too big for Z280RC to solve.

3. There is a chicken way out: Z280RC is RC2014 compatible, so if the problems can't be solved with the resources on-board, perhaps it is time to utilize the numerous RC2014 I/O modules.

PS, you guys may not know this, but September is wine-making time in New Mexico. I have about 70 gallons from my vineyard and need to bottle up 50 gallons of last years' wine to free up carboys. One can write seriously wicked codes with the help of 50 gallons of wine--or not.

You need the DMA because you don't have any FIFO. The DMA +RAM is the FIFO on the Z280 systems so avoids any overrun problems when the CPU is required to disable interrupts for something else like floppy disk I/O.

Depends on what you are doing. A text editor, for example, is not the most demanding sort of application. But if you are using a RT OS (UZI280 is not), then you know that any task can be blocked by a higher priority one; and if the lower priority task was receiving data from the UART, then chances are that the input buffer will overflow if the task is blocked for too long, resulting in characters lost unless hardware handshake is used.

As for the terminal, my VT520 starts missing characters at 9600 baud when scrolling in 132x50 mode.

I knew I had seen that somewhere. Just searched for 'stevie.taz' from UZI280.zip and found this on znode51. Is it the same thing?

...

I've tried the obvious things. I've rewritten the CF card, I've tried loadngo in serial mode. Any diagnostic recommendations to work out wtf happened ?

Alan

Nope. Even tried changing the CPU. My existing one is somewhere between the UK and US and a replacement just arrived here. It will be interesting to learn what happened to the poor thing and get back to Fuzix and maybe MP/M and CP/M 3 hacking for it.

Bill btw has the most excellent customer service I've met

Alan

MOOF!

I've pored over the code multiple times and I'm just not seeing the problem... Probably something really stupid... ;-)

Anyway, I've got a quick question: Did the zsm sources ever get uploaded anywhere (GitHub?)? For some reason it doesn't support the "SET" directive. It's like EQU but allows the value to change; it's useful in REPT, IRPC & IRP groups to count iterations, etc. (See the MAC documentation at www.cpm.z80.de/manuals/mac.pdf section 4.4 (IIRC)).

geowar1 wrote on Sat, 27 October 2018 09:21

Anyway, I've got a quick question: Did the zsm sources ever get uploaded anywhere (GitHub?? For some reason it doesn't support the "SET" directive. It's like EQU but allows the value to change; it's useful in REPT, IRPC & IRP groups to count iterations, etc. (See the MAC documentation at www.cpm.z80.de/manuals/mac.pdf section 4.4 (IIRC).

SET is a Z80 instruction (set bit, like in "set 7,a") and therefore cannot be used as a pseudo-op. What you want is DEFL and is supported by ZSM4. For compatibility with M80, ASET is also implemented, which does the same thing.

Remember that MAC is an 8080 assembler, while ZSM4 is a Z80 relocatable assembler, and thus there are subtle differences between the two (I would suggest using the M80 documentation instead as a guide). When I get some free time I'll prepare some docs, perhaps using the M80 manual as starting point.

Excellent! Just what I needed to know. ;-)
(Thou I'm trying to keep my machines Micro$oft clean... ;-)

Tony,
I downloaded your files and assembled them on my Z280RC without errors. When I run the banked software using the test.sys/test.com method or cpm3.sys/cpmldr3.com method, I got lots of diagnostic messages (a sampe of the message below), but I am not able to issue CP/M commands. How can I work around these diagnostic messages?
Bill

[snip]

?BNKSL Select Bank 01
?BNKSL Select Bank 00A
?BNKSL Select Bank 01
?BNKSL Select Bank 00>
?BNKSL Select Bank 01
MOVE from 010DF4 to 01F12A 234
DMAXFR using DMA3 from P010DF4 to P00F12A count 234
?BNKSL Select Bank 00[/code]

I've been working on the same project off and on for about six weeks...
I've gone over every line of code multiple times and added tons of logging (set "TRACE EQU 2").
I was hanging on boot somewhere in DOS...
Until I realized that the cpmldr in the system tracks wouldn't load the CPM3.SYS built with banked BIOS.
But I could boot into CP/M 2.2 and then run the CPMLDR built with the banked BIOS.
It doesn't appear to have any problems with large files but...
I sent my sources (attached) to BillS to try on his hardware he noticed issues with uninitialized memory.
When I get a chance I'll take a look at your sources and see if I notice anything amiss. ;-)