CPM/Z-80 card for the 1090XL -- Calling anyone with Z-80 experience!

[reifsnyderb]

2 hours ago, ivop said:

Hi,

 

It's a pity the DIP and PLCC versions are discontinued, but I suppose they won't be hard to get anytime soon. Even NMOS 6502 are plenty available as NOS and refurbished.

 

 

I don't know what the supply will be.  I really don't like relying on cannibalized hardware, either.  Western Design sells the W65C02....so when I made the Happy Board there's a couple solder jumpers so all new hardware could be used.

 

2 hours ago, ivop said:

I see you used a RE'd Z80 source for BDOS and CCP. In theory that's fine, but I would not remove the 6 bytes serial at the beginning of BDOS and move BDOSE to $xx00. Some applications rely on it being $xx06 and the zero page vector ending with $06. IIRC ACK compiled applications have that dependency. If I were you, I'd just stick to DRI vanilla source code. You won't gain a full page of memory savings anyway, and it's advised to have each component page aligned.

I had some issues getting it to fit and figured that removing the serial number code was "low hanging fruit".  I'll put them back in.

 

 

2 hours ago, ivop said:

The cross-platform utilities are here: http://www.cpm.z80.de/download/cpm2-plm.zip . Most include source, too

 

 

Thanks!  I was looking all over for z80 utilities and only found what appears to binary dumps.  So, I was trying to see if the binary dumps were legit when I found out about the Z-80 being discontinued.

 

2 hours ago, ivop said:

I don't think you wasted three weeks on this. It's great to see you got to the CCP prompt! Most of the work seems done. Now you "only" need some form of proper terminal emulation and you can run WordStar

 

 

Yeah, I was rather elated to get the CCP prompt up.  It responds as well.  So, if I try the "dir" command, for example, it reads the directory region of the disk. 

 

Since respeQt shows what sectors are being read, I also discovered that CP/M was initially reading one sector before the first sector.  After some troubleshooting, to verify my track/sector to sector translation code was working correctly, I discovered that CP/M was passing a sector 0.  So, there was an off-by-one error.  I had to increment the sector number, to "fix" the off-by-one issue and get the correct sectors to be read.  The documentation wasn't clear as to whether CP/M started with sector 0 or 1.

 

Well, I was elated yesterday, at around 2:00pm, to get the prompt, have issues such as the CR/LF translation working, get keyboard input working, etc.  Only hours later, I find out I am closing in on getting a CPU/Memory board for a soon to be discontinued CPU. 

 

Oh, yeah, the 80 column card appears to work with the CP/M card as well.  Maybe it will run WordStar as-is?

 

Printer support still needs added.  Most of this work is already done and I just need to figure out the proper CIO code for the printer....which should be really similar to the CIO code for screen output.

 

 

 

 

 

[reifsnyderb]

2 hours ago, kheller2 said:

Assuming these are Z80As in the 1090, there are plenty of Sinclair 1000, TRS80s and Colecovisions to contribute

 

I think they are the same.  I don't care to rely on cannibalization, though.

[reifsnyderb]

2 hours ago, scorpio_ny said:

The challenge is still there in spite of the announcement. 🙂 Finish the project and worry about sourcing chips later for deployment.

Yeah.  That's true.  Last night, I just made an agreement with somebody to finish this as he's going to get some chips and sell them to me on an at cost basis.  So, yeah, I'll finish it.  However, if I knew two months ago that the Z-80 would be cancelled this very summer I wouldn't have started this.

 

The current plan is to get a boot disk working and to write a quick and dirty import program so that other software could be imported into the Atari CP/M environment and used.  Then people can import whatever they like.

[+kheller2]

I'm assuming that the same software that runs on the ATR8000, INDUS and even C128 would work just fine once the IO is worked out.

Assuming we get them converted to the 1050 ED/SD format?

 

Another thread that was used to build disks : 

 

 

[reifsnyderb]

17 minutes ago, kheller2 said:

I'm assuming that the same software that runs on the ATR8000, INDUS and even C128 would work just fine once the IO is worked out.

Assuming we get them converted to the 1050 ED/SD format?

 

Another thread that was used to build disks : 

 

 

 

Thanks for the link.  I'll check it out.  The goal is to use 1050 ED disks.  CP/M can only be configured for one disk type, unfortunately.  So, I figured ED disks would have the best compatibility and provide with some extra space over and above that of SSSD disks.  Though, it is probably possible to use SSSD disks but CP/M wouldn't know not too try to put too much data on the disk.

 

 

 

 

 

 

[reifsnyderb]

On the subject of transferring files to CP/M disks.....

 

Currently, I am configuring the boot disk by using scripts to make an ATR image file.  The image file is then provided to the Atari via RespeQt.

 

This may be the easiest way to have files put on an ATR image by "injecting" the files to the correct location, in the image, and adding a directory entry.  Does anyone have an opinion as to if this is the way to go with this or if the Atari should be involved?  My personal opinion is that this is the easiest way to do this.

[+kheller2]

I think there was a large effort involved in getting the proper DD disks created for Indus and ATR.  It might be better to stay in the DD format, but that wasn’t Atari’s direction with the 1090 or sweetpea.  

[ivop]

1 hour ago, reifsnyderb said:

 

I don't know what the supply will be.  I really don't like relying on cannibalized hardware, either.  Western Design sells the W65C02....so when I made the Happy Board there's a couple solder jumpers so all new hardware could be used.

No need to cannibalize hardware IMHO. Looking at Aliexpress/eBay there are tons of refurbished Z80s available for as low as $1 each. Don't know how the "fake" situation is with Z80s though. I recall 6502s are sometimes mislabeled, like a 6502B actually being an A.

 

1 hour ago, reifsnyderb said:

Yeah, I was rather elated to get the CCP prompt up.  It responds as well.  So, if I try the "dir" command, for example, it reads the directory region of the disk. 

Yeah, I remember the first time I got the A> prompt with my emulator. That's an exiting moment

1 hour ago, reifsnyderb said:

Since respeQt shows what sectors are being read, I also discovered that CP/M was initially reading one sector before the first sector.  After some troubleshooting, to verify my track/sector to sector translation code was working correctly, I discovered that CP/M was passing a sector 0.  So, there was an off-by-one error.  I had to increment the sector number, to "fix" the off-by-one issue and get the correct sectors to be read.  The documentation wasn't clear as to whether CP/M started with sector 0 or 1.

Good you found it. I prototyped my 8080 emulator in C and noticed that sectors start at 0, so I was prepared when I did the 6502 code.

 

1 hour ago, reifsnyderb said:

Well, I was elated yesterday, at around 2:00pm, to get the prompt, have issues such as the CR/LF translation working, get keyboard input working, etc.  Only hours later, I find out I am closing in on getting a CPU/Memory board for a soon to be discontinued CPU. 

 

Oh, yeah, the 80 column card appears to work with the CP/M card as well.  Maybe it will run WordStar as-is?

No, that won't work. The Atari E: handler does all sorts of things with high ASCII characters (clear screen, bell at the end of line 3, clear up to 3 lines etc.) which might interfere with CP/M working properly. It's best to have a true dumb terminal that bypasses the E: handler. To get WordStar 3.3 working, you can manually configure that to do VT52, which is very easy. WS only needs position cursor (ESC Y col row). The rest is optional. Don't know about later WS, because 3.3 was the last 8080 version. But VT52 should be enough and has a very limited command set (http://gunkies.org/wiki/VT52 , CP/M-65 implementation: https://github.com/davidgiven/cpm65/blob/master/apps/vt52drv.asm , Atari dumb terminal is in its bios https://github.com/davidgiven/cpm65/blob/master/src/arch/atari800/atari800.S , 80 columns software driver is at https://github.com/davidgiven/cpm65/blob/master/src/arch/atari800/utils/tty80drv.S).

 

Edit: forgot to mention. Regarding the Z80 situation, looking at the notification (https://www.mouser.com/PCN/Littelfuse_PCN_Z84C00.pdf ) it's only the Z80 that's discontinued. Not sure how much effort it takes, but you could upgrade to the DIP-64 Z180. The added DMA would be useless, and the new instructions won't be used, but while you're at it, you might want to break out the build-in UART to a connector.

 

Edit2: https://www.zilog.com/docs/z180/ps0140.pdf

 

Edited April 20 by ivop

[ivop]

22 minutes ago, reifsnyderb said:

This may be the easiest way to have files put on an ATR image by "injecting" the files to the correct location, in the image, and adding a directory entry.  Does anyone have an opinion as to if this is the way to go with this or if the Atari should be involved?  My personal opinion is that this is the easiest way to do this.

At first I would stick to using mkfs.cpm and cpmcp to copy files to it, and then prepend the ATR header. If there are enough users really wanting to copy files directly from a DOS 2.5 disk to a cpmfs disk, it might be worth the trouble to write a specific utility for that. Probably a DOS utility, as CP/M cannot read the boot sectors via its BIOS. I hardly think it's worth the trouble.

 

12 minutes ago, kheller2 said:

I think there was a large effort involved in getting the proper DD disks created for Indus and ATR.  It might be better to stay in the DD format, but that wasn’t Atari’s direction with the 1090 or sweetpea.  

How many reserved tracks does the Indus CP/M use? I think being able to boot with stock hardware (800XL, 1050, 1090) has its merits.

[reifsnyderb]

36 minutes ago, ivop said:

No, that won't work. The Atari E: handler does all sorts of things with high ASCII characters (clear screen, bell at the end of line 3, clear up to 3 lines etc.) which might interfere with CP/M working properly. It's best to have a true dumb terminal that bypasses the E: handler. To get WordStar 3.3 working, you can manually configure that to do VT52, which is very easy. WS only needs position cursor (ESC Y col row). The rest is optional. Don't know about later WS, because 3.3 was the last 8080 version. But VT52 should be enough and has a very limited command set (http://gunkies.org/wiki/VT52 , CP/M-65 implementation: https://github.com/davidgiven/cpm65/blob/master/apps/vt52drv.asm , Atari dumb terminal is in its bios https://github.com/davidgiven/cpm65/blob/master/src/arch/atari800/atari800.S , 80 columns software driver is at https://github.com/davidgiven/cpm65/blob/master/src/arch/atari800/utils/tty80drv.S).

 

Edit: forgot to mention. Regarding the Z80 situation, looking at the notification (https://www.mouser.com/PCN/Littelfuse_PCN_Z84C00.pdf ) it's only the Z80 that's discontinued. Not sure how much effort it takes, but you could upgrade to the DIP-64 Z180. The added DMA would be useless, and the new instructions won't be used, but while you're at it, you might want to break out the build-in UART to a connector.

 

Edit2: https://www.zilog.com/docs/z180/ps0140.pdf

 

If only the ESC Y col row is needed, why not just intercept the command and tell the Atari OS to just re-position the cursor?  The same could be done for any other VT52 cases.

 

Here's the current code to send the console output....

 

;	--------------------------------------------------------------------
;	SEND CONSOLE OUTPUT
;	--------------------------------------------------------------------
SR12:
	; NOTE IOBYTE will have to be checked to ensure it is properly converted from ASCII to ATASCII !!!!!!!!!

	LDA	IOBYTE
	CMP	#$0A					; Don't print $0A (line feeds)
	BNE	SR12A
	JMP	Z80RET
SR12A:
	CMP	#$0D					; Convert $0D (carriage ret) to $9B
	BNE	SR12B
	LDA	#$9B
	STA	IOBYTE
SR12B:

	LDX	#$00					; Select IOCB 0
	LDA	#PUTCHR		; Put a byte command
	STA	ICCOM,X
	LDA	#$00					; Message length
	STA	ICBLH,X
	STA	ICBLL,X
	LDA	IOBYTE				; Byte to print in A
	JSR CIOV

	JMP	Z80RET

 

 

While I am at it, here's the console input code....

 

 

;	--------------------------------------------------------------------
;	GET CONSOLE INPUT
;	--------------------------------------------------------------------
SR11:

	LDX	#$10				; Select IOCB 1	keyboard
	LDA	#GETCHR	; Put a byte command
	STA	ICCOM,X
	LDA	#$00				; Message length
	STA	ICBLH,X
	STA	ICBLL,X
	JSR 	CIOV

	CMP	#$9B				; Check for RETURN key.
	BNE	SR11A
	LDA	#$0A				; Convert the return key to a line feed.

SR11A
	ORA	#$00				; Do something to set the accumulator flags
	BMI		SR11				; If bit 7 is set, reject input and get another key.
	STA	IOBYTE			; Save IOBYTE 

	; NOTE:  DOES ANYTHING ELSE NEED TO BE DONE TO ENSURE A PROPER VALUE WAS ENTERED??

	JMP	Z80RET

 

 

I didn't see that mouser is selling any DIP 64 Z-180 chips.

 

 

 

 

 

 

 

 

 

 

 

 

[reifsnyderb]

53 minutes ago, kheller2 said:

I think there was a large effort involved in getting the proper DD disks created for Indus and ATR.  It might be better to stay in the DD format, but that wasn’t Atari’s direction with the 1090 or sweetpea.  

While DD disks would be nice, it would break compatibility with a non-upgraded 1050.  I am figuring that, most likely, an XL or XE computer won't be running an 810.  But, that's not really a guarantee.

[sup8pdct]

On 4/6/2024 at 2:29 PM, sup8pdct said:

Digging into the files, i found some following files.

The bios is the 64k version.

Have also found a number of boot sectors. Not the bits for cpm tho

atcopy.com 1.25 kB · 3 downloads atsysgen.com 1.5 kB · 4 downloads atformat.com 768 B · 3 downloads atbios.com 61.25 kB · 4 downloads some boot sectors.atr 98.02 kB · 4 downloads

Did you do a cp/m Dir on the above ATR? it should show the files above. (provided i did it right)

I did a dissembley of those files. The ATformat only formats in single density.

Edited April 20 by sup8pdct
update information

[reifsnyderb]

39 minutes ago, ivop said:

At first I would stick to using mkfs.cpm and cpmcp to copy files to it, and then prepend the ATR header. If there are enough users really wanting to copy files directly from a DOS 2.5 disk to a cpmfs disk, it might be worth the trouble to write a specific utility for that. Probably a DOS utility, as CP/M cannot read the boot sectors via its BIOS. I hardly think it's worth the trouble.

To create a boot disk, I wrote a quick and dirty C program that reads a blank ATR image, reads a binary file, then merges everything into a 3rd file by copying the binary file at a specified offset.  Then, I run a batch file 4 times to install everything into the ATR image.  This C program could easily be modified so as to add other files and the proper directory entries.  Right now, it's compiled to run in Linux.  I suppose a DOS version could be created as well.

 

[reifsnyderb]

2 minutes ago, sup8pdct said:

Did you do a cp/m Dir on the above ATR? it should show the files above. (provided i did it right)

I haven't got to that point yet.  There is a problem in that it appeared Atari was going to use SSSD disks and I went with SSED disks.  So, I am thinking there would be a compatibility problem.

[sup8pdct]

1 minute ago, reifsnyderb said:

I haven't got to that point yet.  There is a problem in that it appeared Atari was going to use SSSD disks and I went with SSED disks.  So, I am thinking there would be a compatibility problem.

Wont be hard to change. depends if you put directory at track 3 for enhanced or single or at a sector offset.

[reifsnyderb]

5 minutes ago, sup8pdct said:

Wont be hard to change. depends if you put directory at track 3 for enhanced or single or at a sector offset.

You are right!  It may not make a difference if the directory is at track 3 for both.  The ED disks are also at track 3.  I'll see what happens....

[sup8pdct]

Here is hopefully the enhanced density version.

some boot sectors ed.atr

Edited April 20 by sup8pdct
oopsy

[ivop]

35 minutes ago, reifsnyderb said:

If only the ESC Y col row is needed, why not just intercept the command and tell the Atari OS to just re-position the cursor?  The same could be done for any other VT52 cases.

Yes, that's possible. But he Atari would still behave funny with the three line buffer and all. And the E: handler is very slow.

35 minutes ago, reifsnyderb said:

Here's the current code to send the console output....

This is what my first CP/M-65 BIOS did, too. But when I compared DUMP DUMP.COM between the Atari and the BBC, I quickly decided to ditch the E: handler and write a dumb terminal. If you look just at conout (the TTY driver, ignore the screen driver), it's really very simple. I reused the row and column addresses the Atari OS uses.

42 minutes ago, reifsnyderb said:

I didn't see that mouser is selling any DIP 64 Z-180 chips.

I see. Googling around it seems they are harder to get than Z80s. So that's not a useful replacement either.

[FifthPlayer]

3 hours ago, reifsnyderb said:

I think they are the same.  I don't care to rely on cannibalization, though.

If the chip is coming from an otherwise dead TRS-80/Colecovision/etc, it's not cannibalization as much as it is recycling, giving a still-useful chip a new lease on life.  I wouldn't discount this as a source.

[sup8pdct]

On subject of text translation, I found the following tabels, as a text file. It may help.

It is also in .OBJ.x files but there many extra bytes that shouldn't be in them.

Also part of boot image, but again many extra bytes included.

 

 

CPMTABLES.LIS.5

[reifsnyderb]

30 minutes ago, ivop said:

But he Atari would still behave funny with the three line buffer and all. And the E: handler is very slow.

 

This is what my first CP/M-65 BIOS did, too. But when I compared DUMP DUMP.COM between the Atari and the BBC, I quickly decided to ditch the E: handler and write a dumb terminal. If you look just at conout (the TTY driver, ignore the screen driver), it's really very simple. I reused the row and column addresses the Atari OS uses.

I suppose the 3 character buffer could be handled either in the CP/M BIOS or in the Atari I/O.  I think it would be much faster to do this in the CP/M BIOS.

 

The 80 column cards don't really use E:.  They use their own E: handler. 

 

 

[ivop]

1 hour ago, reifsnyderb said:

I suppose the 3 character buffer could be handled either in the CP/M BIOS or in the Atari I/O.  I think it would be much faster to do this in the CP/M BIOS.

VT52 is easiest implemented as a state machine on the Atari side. No need to buffer characters. If you would do it in CONOUT at the Z80 side, you would need to devise a method to signal all the different VT52 "instructions" to the Atari, defeating the purpose. It's the Atari side that needs to manipulate the display.

[_The Doctor__]

XF551, Percoms, and USDoubler etc. are all good things too. My CP/M machine was two 8 inch and a Hard Drive, ADDS+ terminal and a few extras like RAM, ROM sim, network card, video card, etc. Like most thngs, purpose built

[reifsnyderb]

10 hours ago, ivop said:

I see you used a RE'd Z80 source for BDOS and CCP. In theory that's fine, but I would not remove the 6 bytes serial at the beginning of BDOS and move BDOSE to $xx00. Some applications rely on it being $xx06 and the zero page vector ending with $06. IIRC ACK compiled applications have that dependency. If I were you, I'd just stick to DRI vanilla source code. You won't gain a full page of memory savings anyway, and it's advised to have each component page aligned.

 

 

I just started to take a look at this.  I removed the serial number code from CCP.  Did you mean to keep the serial number code in CCP as it's not in BDOS? 

 

The beginning of BDOS is at $EC00.  Should BDOS really start at $EC06?  The BIOS would have to change the zero page vector to $EC06, of course.

 

I thought the purpose of having the zero page vector was so that applications could find BDOS.....

 

 

;   Set origin for BDOS
	ORG	$EC00

;
;**************************************************************
;*
;*                    B D O S   E N T R Y
;*
;**************************************************************
;
FBASE:	JP	FBASE1
;
;   Bdos error table.
;
BADSCTR:DW	ERROR1		;bad sector on read or write.
BADSLCT:DW	ERROR2		;bad disk select.
RODISK:	DW	ERROR3		;disk is read only.
ROFILE:	DW	ERROR4		;file is read only.
;
;   Entry into bdos. (DE) or (E) are the parameters passed. The
; function number desired is in register (C).
;
FBASE1:	EX	DE,HL		;save the (DE) parameters.
	LD	(PARAMS),HL
	EX	DE,HL
	LD	A,E		;and save register (E) in particular.
	LD	(EPARAM),A
	LD	HL,0
	LD	(STATUS),HL	;clear return status.
	ADD	HL,SP
	LD	(USRSTACK),HL	;save users stack pointer.
	LD	SP,STKAREA	;and set our own.
	XOR	A		;clear auto select storage space.
	LD	(AUTOFLAG),A
	LD	(AUTO),A
	LD	HL,GOBACK	;set return address.

 

 

 

 

[reifsnyderb]

6 hours ago, sup8pdct said:

Did you do a cp/m Dir on the above ATR? it should show the files above. (provided i did it right)

I did a dissembley of those files. The ATformat only formats in single density.

I just tried it as B: and didn't see any files.  So, there are two possibilities.  Either the ATR isn't quite right or my CP/M implementation needs fixed.  This is the first time I've tried this, so I don't know yet.

 

 

Edit to add....

 

Track 3, Sector 1 should be Sector 79 on an Atari disk.  So, that being said, and if my math is correct, sector 79 would start at offset 10112.  The directory should have the user byte and filename first.  So, I am thinking that the directory entries, and possibly files (?) all need shifted by 16 bytes.

 

 

 

 

Edited April 21 by reifsnyderb