• Please review our updated Terms and Rules here

HELP: Frame Error when using PCGET to recieve files

R

rpiguy2

Experienced Member
Joined
Dec 15, 2016
Messages
310
Location
New Jersey
I have a CP/M small board computer based on the Z180. It has two UARTs built in: ASCII-0 and ASCII-1.

I use ASCII-0 for the terminal and ASCII-1 for file transfers.

I can transfer files to PC/MAC no problem via ASCII-1, but when I try to transfer files (XMODEM or XMODEM-1) from the MAC/PC to CP/M using PCGET it always generates a FRAME ERROR and fails.

I know the serial port settings are correct because I can send to the PC no problem.

What is causing this? I am using Putty with the file transfer extensions.

CP/M 2.2

***

Related topic, is there anyway to directly write to an 8MB SD Card CP/M partition that I made on a Windows device.

I am trying to fill that said partition with software, but since I cannot get PCGET to work it would be very convenient if I could just plug the SD card into my PC and drag the CP/M files over to it.
 
To read the CP/M formatted card on a Windows device you need cpmtools. Plus a disk definition that matches the format of your CF card partition. Do you have the BIOS source code? You can read the definition from it. Being 8MB, it's possible it is using Grant Searle's CF card format. This divides a 128MB card into 16x8MB partitions and I derived my own drivers from it, maintaining the single track boot section on each partition. So my scheme has the following cpmtools definitions:

Code: 
diskdef uIDE0
  seclen 512
  tracks 512
  sectrk 32
  blocksize 4096
  maxdir 512
  skew 0
  boottrk 1
  os 3
end

diskdef uIDE1
  seclen 512
  tracks 1024
  sectrk 32
  blocksize 4096
  maxdir 512
  skew 0
  boottrk 513
  os 3
end

diskdef uIDE2
  seclen 512
  tracks 1536
  sectrk 32
  blocksize 4096
  maxdir 512
  skew 0
  boottrk 1025
  os 3
end

diskdef uIDE3
  seclen 512
  tracks 2048
  sectrk 32
  blocksize 4096
  maxdir 512
  skew 0
  boottrk 1537
  os 3
end

diskdef uIDE4
  seclen 512
  tracks 2560
  sectrk 32
  blocksize 4096
  maxdir 512
  skew 0
  boottrk 2049
  os 3
end

diskdef uIDE5
  seclen 512
  tracks 3072
  sectrk 32
  blocksize 4096
  maxdir 512
  skew 0
  boottrk 2561
  os 3
end

diskdef uIDE6
  seclen 512
  tracks 3584
  sectrk 32
  blocksize 4096
  maxdir 512
  skew 0
  boottrk 3073
  os 3
end

diskdef uIDE7
  seclen 512
  tracks 4096
  sectrk 32
  blocksize 4096
  maxdir 512
  skew 0
  boottrk 3585
  os 3
end

diskdef uIDE8
  seclen 512
  tracks 4608
  sectrk 32
  blocksize 4096
  maxdir 512
  skew 0
  boottrk 4097
  os 3
end

diskdef uIDE9
  seclen 512
  tracks 5120
  sectrk 32
  blocksize 4096
  maxdir 512
  skew 0
  boottrk 4609
  os 3
end

diskdef uIDE10
  seclen 512
  tracks 5632
  sectrk 32
  blocksize 4096
  maxdir 512
  skew 0
  boottrk 5121
  os 3
end

diskdef uIDE11
  seclen 512
  tracks 6144
  sectrk 32
  blocksize 4096
  maxdir 512
  skew 0
  boottrk 5633
  os 3
end

diskdef uIDE12
  seclen 512
  tracks 6656
  sectrk 32
  blocksize 4096
  maxdir 512
  skew 0
  boottrk 6145
  os 3
end

diskdef uIDE13
  seclen 512
  tracks 7168
  sectrk 32
  blocksize 4096
  maxdir 512
  skew 0
  boottrk 6657
  os 3
end

diskdef uIDE14
  seclen 512
  tracks 7680
  sectrk 32
  blocksize 4096
  maxdir 512
  skew 0
  boottrk 7169
  os 3
end

diskdef uIDE15
  seclen 512
  tracks 8192
  sectrk 32
  blocksize 4096
  maxdir 512
  skew 0
  boottrk 7681
  os 3
end

See if you can read your card with the definition for uIDE0.

When I produced my uIDE interface I wrote a stack of instructions that you may find useful: http://www.cpcwiki.eu/index.php/UID..._computers#uIDE_disk_image_and_utils_download

There is a download file with cpmtools and a disk image full of CP/M software from the N8VEM project, along with some cpmtools guidance.
 
Last edited:
JonB said:
To read the CP/M formatted card on a Windows device you need cpmtools. Plus a disk definition that matches the format of your CF card partition. Do you have the BIOS source code? You can read the definition from it. Being 8MB, it's possible it is using Grant Searle's CF card format. This divides a 128MB card into 16x8MB partitions and I derived my own drivers from it, maintaining the single track boot section on each partition. So my scheme has the following cpmtools definitions:

When I produced my uIDE interface I wrote a stack of instructions that you may find useful: http://www.cpcwiki.eu/index.php/UID..._computers#uIDE_disk_image_and_utils_download

...

There is a download file with cpmtools and a disk image full of CP/M software from the N8VEM project, along with some cpmtools guidance.
Click to expand...


Thanks this is useful, but will require more playing around on my part. The SD Card in my SBC is not using IDE, it is interfaced directly with the SD Card via SPI.

I just took a look at the BIOS per your recommendation and the SD card handling is pretty nicely laid out it can even be adjusted to work with newer, faster SXDC cards.

The only disk structure detail I could gleam from it was a 512 Byte sector length, which matches the physical sectors on SD Cards.

I only have perfunctory knowledge of CP/M - is there anyway for me to examine the partition from within CP/M to get the rest of the information for CPMtools?
 
Just look for the disk definition in the bios source code. All of what you need is there. If in doubt, post a link and I’ll have a look.

Yes I do realise you are not using an IDE interface but that is not the point. It’s the way the CP/M format is arranged that’s important and as I said, Grant’s CF card and SD card implementations have the same logical format (with different hardware interfacing, obviously).

If you don’t have the BIOS source code we can use DDT or ZDT and look at what is in memory (the disk deaf are there for example).
 
JonB said:
Just look for the disk definition in the bios source code. All of what you need is there. If in doubt, post a link and I’ll have a look.

Yes I do realise you are not using an IDE interface but that is not the point. It’s the way the CP/M format is arranged that’s important and as I said, Grant’s CF card and SD card implementations have the same logical format (with different hardware interfacing, obviously).

If you don’t have the BIOS source code we can use DDT or ZDT and look at what is in memory (the disk deaf are there for example).
Click to expand...

BIOS attached - thanks!
 

Attachments

  • MZC36lst.zip
    117 KB · Views: 1
JonB said:
Just look for the disk definition in the bios source code. All of what you need is there. If in doubt, post a link and I’ll have a look.

Yes I do realise you are not using an IDE interface but that is not the point. It’s the way the CP/M format is arranged that’s important and as I said, Grant’s CF card and SD card implementations have the same logical format (with different hardware interfacing, obviously).

If you don’t have the BIOS source code we can use DDT or ZDT and look at what is in memory (the disk deaf are there for example).
Click to expand...

FOUND IT!

Code: 
  FEC3                          DPB_SD    EQU      $                        ; Disk Parameter Block - SD card 8MB partition
                                ;                                 ;        N.B. SPT & BLS changes require MZC_SD changes
                                ;                                 ;             DRM changes require MZC_FMT changes
  FEC3    0004                            DW       512/128                  ;    SPT - Sectors Per 512 byte Track
  FEC5    06                              DB       6                        ;    BSH - Block SHift factor
  FEC6    3F                              DB       63                       ;    BLM :    BLS = 8,192
  FEC7    03                              DB       3                        ;    EXM - EXtent Mask
  FEC8    03FF                            DW       1024-1                   ;    DSM - Storage capacity in BLS -1
  FECA    02FF                            DW       768-1                    ;    DRM - Directory entries
  FECC    E0 00                           DB       0E0h,0                   ;    AL0+AL1 - Three BLS for directory
  FECE    0000                            DW       0                        ;    CKS - Directory check vector - N/A
                                ; <===    DW    0                 ;    OFF - Reserved tracks
                                ;   N.B. DPB_OFF and DPH_XLT are both 0 and don't change so they share the same word
                                ;
  FED0                          DPH_SD1   EQU      $                        ; Disk Parameter Header - First SD partition
  FED0    0000                            DW       0                        ;    XLT - Translation vector - N/A
 
SPT looks unusual. Sectors per 512 byte track? So the disk is set up with 4 x 128 byte sectors per track? You're not going to fit much on there... unless it is configured with a lot of tracks... it uses LBA anyway..

This definition is not the same as Grant's, so you can't use any of the uIDE definitions. You'll have to create your own and add it to the cpmtools diskdefs file.
 
I recall trying to talk someone out of using 4 SPT awhile ago. It really perturbs the computations being done in the BDOS, making it rather sub-optimal. I think they did it to simplify, by some definition, the sector and track computations done in the BIOS.
 
Interesting point, Doug. I hadn't considered the effect of these settings on the BDOS... but, if you are using LBA to access the drive, it is simply a matter of RLCs to compute LBA from Drive / Sector / Track numbers.

For example:

Code: 
; Note: Written by Grant Searle; commentary by JonB
;-----------------------------------------------------------------------------
; Convert track/head/sector into LBA for physical access to the disk
; and set the LBA registers on the drive, ready for a read or write.
;
; IDE sector address:
;  _______________________________________________________________________
; |          LBA2         |        LBA1           |        LBA0           |
; |0  0  0  0  0  0  D3 D2|D1 D0 T8 T7 T6 T5 T4 T3|T2 T1 T0 S4 S3 S2 S1 S0|
;  -----------------------------------------------------------------------
;
; 	Dn : Disk number, 4 bits for 16 disks
; 	Tn : Track number, 9 bits for 512 tracks per disk
; 	Sn : Sector number, 5 bits for 32 sectors of 512 bytes
;
; To build this we need to roll parts of the drive / track / sector numbers
; and combine them to produce values for LBA 0-2.
;-----------------------------------------------------------------------------
setLBAaddr:
	ld	hl,(HSTTRK)	; get track number
	rlc	l		; roll lower 3 bits to top 3
	rlc	l		; (moves T0 T1 and T2 into position)
	rlc	l		; 
	rlc	l		; 
	rlc	l		; (..5 times)
	ld	a,l
	and	0E0h		; mask out bottom 5 bits
	ld	l,a		; copy back to L
	ld	a,(HSTSEC)	; now get sector number
	add	a,l		; add in
	ld	(lba0),a	; store in lba0

	ld	hl,(HSTTRK)	; get track number again
	rrc	l		; roll top 5 bits to lower 5 bits
	rrc	l		; (moves T3 - T7 into position)
	rrc	l		;
	ld	a,l		; get result
	and	01Fh		; mask out upper 3 bits
	ld	l,a		; save back
	rlc	h		; deal with T8 bit
	rlc	h		; roll to bit 5
	rlc	h		;
	rlc	h		;
	rlc	h		;
	ld	a,h		; retrieve result
	and	020h		; mask T8 bit
	ld	h,a		; copy back
	ld	a,(HSTDSK)	; get the drive number (0-15)
	rlc	a		; roll drive number to top 2 bits
	rlc	a		; (moves D0 and D1 into position)
	rlc	a		;
	rlc	a		;
	rlc	a		;
	rlc	a		;
	and	0C0h		; mask out unwanted bits 0-5
	add	a,h		; combine the T8 bit
	add	a,l		; combine T3 - T7 bits
	ld	(lba1),a	; store in lba1
        
	ld	a,(HSTDSK)	; get the drive number again
	rrc	a		; roll twice right
	rrc	a		; (moves D3 and D4 into position)
	and	03h		; mask out unwanted bits (leaves b0 & b1)
	ld	(lba2),a	; store

	; All set, now tell the drive
	call	isSlave		; check for slave drive designation
	jr	nz,setslv	; if so, skip next
	LD	a,CF_MASTER	; otherwise it is master, set master mode
	jr	setlba3		; skip next
setslv:	ld	a,CF_SLAVE	; set slave mode
setlba3:ld	(lba3),A	; done
	ld	a,(lba0)	; set LBA0 address
	out 	(CF_LBA0),a	;
	ld	a,(lba1)	; set LBA1 address
	out 	(CF_LBA1),a	;
	ld	a,(lba2)	; set LBA2 address
	out 	(CF_LBA2),a	;
	ld	A,(lba3)	; set drive (master/slave)
	out 	(CF_LBA3),a	;
	ld 	a,1		; Only one sector required
	out 	(CF_SECCOUNT),a	;
	ret			; done

But the BIOS code for this SBC looks proper complex to me, and it lives in ROM.
 
Last edited:
JonB said:
Interesting point, Doug. I hadn't considered the effect of these settings on the BDOS... but, if you are using LBA to access the drive, it is simply a matter of RLCs to compute LBA from Drive / Sector / Track numbers.
...
But the BIOS code for this SBC looks proper complex to me, and it lives in ROM.
Click to expand...

Right, that code would have a DPB SPT of 128 (based on the comments). So, wonder what the "4" was about. Must be a different BIOS. Certainly, some "obtuse" shifting and ORing is more complex, but done to reduce the BDOS time spent doing division by subtraction. In this case, the BDOS would perform 32x more subtraction loops with SPT=4 compared to SPT=128. Even that SPT=128 code is bit messy - could be optimized considerably.
 
As the original developer of OP's hardware and author of that BIOS, I can say that the I/O driver in the BIOS was optimized for it's efficiency and not that of any system that may make CALLs to it. The reason for SPT=4 (i.e. the same as SD card transfer size) is that this BIOS has multiple 512 byte SD buffers, an LRU algorithm, proper handling of writes to unallocated blocks, a 25 MHz SPI interface in a CPLD, etc. SPT=4 means that conversion to LBA or SDSC is very straightforward and requires 16384 tracks for the 8MB partition. That code is currently under review / revision to allow for a full 512MB "disk" under CP/M-3 or MP/M.

As to the BIOS in ROM: This system at 36.864MHz [re]boots nearly instantaneously to the embedded CP/M 2.2 system. The provided source code also has a conditional assembly variable that allows for development activities by allowing a new BIOS to be invoked as a regular .COM program which relocates it and supercedes the resident BIOS.

As to OP's problem with PCGET: During testing I have transferred many dozens (hundreds?) of MB of binary data via PCGET / PCPUT at 115,200 using HyperTerm and verified them via FC without problem. Indeed, all the files on OP's ROMdisk were created using the as-shipped version of PCGET on that exact system. That unique version of PCGET uses RTS/CTS handshaking on a USB interface (SiLabs driver) and I would suspect the real issue may be a problem with Putty or it's configuration.

System description: View attachment MinZ-C.pdf
 
Gosh that's small! I am thinking "Where can I get one?" but as I have something similar already that rarely gets used... maybe not...
 
I am thinking "Where can I get one?" ...
Click to expand...
I built a small batch of these and made them available to RetroBrew members. I have pretty well all the parts for another four of them and will be building them as time permits. Right now these systems are hand assembled and tested which takes a lot of time.

Although I haven't tried them, USB-A to Mini-B integrated adapters are available which would allow this system to be hung directly off a PC's USB port without needing a cable.

Re OP's original problem: Which version of Putty are you using? HyperTerm seems to work fine and I haven't received any reports of problems from others that are using TeraTerm.
 
You must log in or register to reply here.
Back
Top