Jump to content
IGNORED

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


Recommended Posts

31 minutes ago, ivop said:

Here's the Atari side of things. This is the main loop that runs to handle requests made by CP/M. Again (twice) they use self-modifying code. See JSR DUMMY. I did not convert weird syntax to mads, like LDA X,LABEL but it's readable as it is. BTW some of their tools seem to be hidden in the CPMFILES* hexdumps. No Z80 source code though.

 

 

cpmmain.asm 10.42 kB · 0 downloads

Fantastic!  Thank you!  This code saves a lot of time.

New Z-80/CPM card design. While the back side still needs completed, here's the card around 95% complete. Not too much needs to be done with the back, either. Since I used 4 PLD chips, I decided to go with an Atari styled card using all through-hole technology. The long top chip is the Z-80 and the chip below it is the SRAM chip. Putting everything on one board will free up a card slot and create a much cheaper solution. The Atari replica boards would have retailed for several hundred dollars, after accounting for the fact that some chips are no longer made and other components are hard to find. This new board should be under $100, be more than 3 times faster than the first Z-80 board, has the memory integrated on the board, and uses DMA to transfer data between the Atari/host and the Z-80.

 

newcpmcard.thumb.png.607dbc7b960331c0bd9428b656bd9a76.png

  • Like 4

So it will share the memory and have active windows into each other as expected with the redesign? That's DMA both ways, Atari into Z80 and Z80 into Atari?

Will the memory be seen as Atari Memory when Z80 is off like the standard memory cards?

1 minute ago, _The Doctor__ said:

So it will share the memory and have active windows into each other as expected with the redesign? That's DMA both ways, Atari into Z80 and Z80 into Atari?

Will the memory be seen as Atari Memory when Z80 is off like the standard memory cards?

This card will function as we currently understand the Z-80 card, and it's memory, to have functioned.  The Z-80 memory will be accessible by the Atari through the normal banking window at $4000-$7FFF.  One difference is that instead of using $D1FE, to change the banks, $D1F1 will be used.  (I did this so as to keep compatibility with the original 64k card.)  An extra control line has also been added so that the memory will function properly with modern cards.  The Z-80 never was able to access the main memory on the Atari.  The memory could be used as Atari memory when the Z-80 is off.  (I am not sure why you may want to do this, but it is an option.)

 

I've used the registers I mapped out from the CPM card schematic for $D1F0 as follows:

 

Bit 0 Write Z80 /RESET

Bit 1 Write Z80 /INT

Bit 2 Write Z80 /BUSRQ

Bit 3 Write Z80 RAM Enable (Active High)

Bit 6 Read Z80 /BUSAK

Bit 7 Read Z80 D7

 

The plan is as follows:

  1.  Start the computer with the Z-80 reset line held low. 

  2.  The Atari will bank the Z-80 memory in via $D1F1 to pre-load it.

  3.  Once pre-loaded, the Atari will raise the Z-80 /Reset line to start the Z-80.

  4.  The Atari will be the host/master.

  5.  The Atari will monitor $D1F0, bit 7 to check for I/O requests from the Z-80.

  6.  When the Atari needs DMA, it must issue a /BUSRQ.  ($D1F0, bit 2)  The Z-80 will respond with a /BUSAK.  ($D1F0, bit 6)  Only then can the Atari bank in the memory.

  7.  There is a frame structure and buffer, within the Z-80's memory, to use for DMA.

 

There's more details to work out, of course.

 

 

 

 

 

 

  • Like 2
1 minute ago, Geister said:

Can the Z-80 card use the 80-column card for video output?   It seems like that was meant to work.

Yes.  All I/O would go through Atari's device handlers.  So, if an 80 column card would be installed, you would have 80 column video output.

5 minutes ago, Geister said:

Since the video card also shares the header that the Z-80 and memory card use, I was guessing that there may be a direct usage mode or signals to bypass the Atari and go directly to the video card.

In theory, this would be possible.  However, none of the cards have ever been wired to work this way.  (Atari's cards were never wired to work this way, either.)  Also, Atari's normal I/O region is incompatible with the CP/M memory model.

 

The 1090XL is configured such that a card could disable the address line transceivers and take complete control over the 1090XL's bus.  In normal operation, even the data bus lines have to be enabled by a card.  A properly configured card could use the 1090XL as a bus for a computer that is not connected to an Atari. 

  • Like 1

FYI there are CP/M experts still developing Z-80 boards. Stephen C. Cousins in the UK has over (100) Z-80 boards for sale at Tindie store

 

There is extensive documentation for all of his boards at Link

 

He appears to be a good source of info if you want to figure out how to put CP/M on Atari disks

 

 

  • Like 3
  • Thanks 1
9 hours ago, Geister said:

Yeah, I was kind of thinking about the SWP ATR8000 and how that could be a stand-alone computer.

It could be.  There was a special cable that you used to connect a serial terminal to the sio port on the ATR.  No Atari needed to run CPM. 

Boards are ordered.

 

I started building a memory map so as to have a better idea where everything goes.  Here it is....

 

1090XL Z-80 Card CP/M Information

 

CP/M Memory Map for 64k System’s

 

 

0000 Start of Memory

0000 Low Storage System Buffers & Parameters

0000 Jump to BIOS (JMP FA00)

0003 IO Byte

Under some BIOSes sets the device for the output. Checked with BDOS

call 7 and set with BDOS call 8.

 

BDOS function 7 – Get I/O byte. Entered with C=7 and returns I/O byte.

BDOS function 8 – Set I/O byte. Entered with C=8 and E=I/O byte.

 

0004 DSK Byte

0005 BDOS System Call (JMP E400)

0008 Restart Vector 1

0010 Restart Vector 2

0018 Restart Vector 3

0020 Restart Vector 4

0028 Restart Vector 5

0030 Restart Vector 6

0038 Restart Vector 7

0040 BIOS Work Area

0050 Unused (in CP/M 2.2)

0060 FCB – Default File Control Block

0060 Drive Number (0 = Current Drive, 1 = Drive A:, 2 = Drive B:)

0061 Filename

Filename is 7-bit ASCII. The top bits (bit 7) of the filename bytes are

usually referred to as “F1” to “F8” and have the following meanings:

F1-F4 User defined attributes. Any program can use them in any way it

likes. The filename in the disk directory has the corresponding

bits set.

F5-F8 Interface attributes. They modify the behavior of the various

BDOS functions or indicate error conditions. In the directory

these bits are always zero.

0069 File type

File type is 7-bit ASCII. The top bits (bit 7) of the file type bytes are

usually referred to as “T1” to “T3” and have the following meanings:

T1 Read-Only

T2 System (hidden)

T3 Archive – Set if the file has not been changed since it was last

copied.

006C EX

006D S1 Reserved

006E S2 Reserved

007F RC Number of 128 byte “records” in this file.

0070 Data Map (16 Bytes) – Number of each consecutive sector on the disk that is

used to store this file.

0080 cr

0081 Direct Memory Address

0100

TPA Transient Program Area

(Free Memory for Programs)

 

E400

  CCP Command Line Interpreter

 

EC00

  BDOS Operating System Functions

 

FA00

BIOS Hardware Drivers for BDOS

FA00 Jump vector table for individual BIOS subroutines

FA00 JP boot ;cold start

FA03 JP wboot ;warm start

FA06 JP const ;console status

FA09 JP conin ;console character in

FA0C JP conout ;console character out

FA0F JP list ;list character out

FA12 JP punch ;punch character out

FA15 JP reader ;reader character out

FA18 JP home ;move head to home position

FA1B JP seldsk ;select disk

FA1E JP settrk ;set track number

FA21 JP setsec ;set sector number

FA24 JP setdma ;set dma address

FA27 JP read ;read disk

FA2A JP write ;write disk

FA2D JP listst ;return list status

FA30 JP sectran ;sector translate

 

FFFF Top of 64k Memory

 

 

 

Unfortunately, indents were removed.  I am also gathering everything else I can find and/or has been posted that helps and putting it in one big document.

 

 

  • Like 2
34 minutes ago, reifsnyderb said:

Unfortunately, indents were removed.  I am also gathering everything else I can find and/or has been posted that helps and putting it in one big document.

Use "code" mode:

image.thumb.png.b3a43223897be19eb12871efb3127b3d.png

and then "No Syntax Highlighting"

image.thumb.png.4452e71eacf99a227b53e27b5846f456.png

 

 

 

  • Thanks 1

 

Thanks @DjayBee !

 

Here it is with indents!

 

1090XL Z-80 Card CP/M Information

CP/M Memory Map for 64k System’s


0000			Start of Memory
	0000		Low Storage	System Buffers & Parameters
		0000	Jump to BIOS		(JMP FA00)
		0003	IO Byte
				Under some BIOSes sets the device for the output.  Checked with BDOS 
				call 7 and set with BDOS call 8.

				BDOS function 7 – Get I/O byte.  Entered with C=7 and returns I/O byte.
				BDOS function 8 – Set I/O byte.  Entered with C=8 and E=I/O byte.

		0004	DSK Byte
		0005	BDOS System Call	(JMP E400)
		0008	Restart Vector 1
		0010	Restart Vector 2
		0018	Restart Vector 3
		0020	Restart Vector 4
		0028	Restart Vector 5
		0030	Restart Vector 6
		0038	Restart Vector 7
		0040	BIOS Work Area
		0050	Unused (in CP/M 2.2)
	0060		FCB – Default File Control Block
		0060	Drive Number (0 = Current Drive, 1 = Drive A:, 2 = Drive B:)
		0061	Filename
				Filename is 7-bit ASCII.  The top bits (bit 7) of the filename bytes are
				usually referred to as “F1” to “F8” and have the following meanings:
				F1-F4	User defined attributes.  Any program can use them in any way it
					likes.  The filename in the disk directory has the corresponding
					bits set.
				F5-F8	Interface attributes.  They modify the behavior of the various
					BDOS functions or indicate error conditions.  In the directory
					these bits are always zero.
		0069	File type
				File type is 7-bit ASCII.  The top bits (bit 7) of the file type bytes are 
				usually referred to as “T1” to “T3” and have the following meanings:
				T1	Read-Only
				T2	System (hidden)
				T3	Archive – Set if the file has not been changed since it was last
					copied.
		006C	EX
		006D	S1	Reserved
		006E	S2	Reserved
		007F	RC	Number of 128 byte “records” in this file.
		0070	Data Map (16 Bytes) – Number of each consecutive sector on the disk that is
			used to store this file.
		0080	cr
		0081	Direct Memory Address
		
0100
			TPA		Transient Program Area
					(Free Memory for Programs)

E400
			CCP		Command Line Interpreter

EC00
			BDOS		Operating System Functions

FA00
			BIOS		Hardware Drivers for BDOS	
	FA00		Jump vector table for individual BIOS subroutines
		FA00		JP	boot		;cold start
		FA03		JP	wboot		;warm start
		FA06		JP	const		;console status
		FA09		JP	conin		;console character in
		FA0C		JP	conout		;console character out
		FA0F		JP	list		;list character out
		FA12		JP	punch		;punch character out
		FA15		JP	reader		;reader character out
		FA18		JP	home		;move head to home position
		FA1B		JP	seldsk		;select disk
		FA1E		JP	settrk		;set track number
		FA21		JP	setsec		;set sector number
		FA24		JP	setdma		;set dma address
		FA27		JP	read		;read disk
		FA2A		JP	write		;write disk
		FA2D		JP	listst		;return list status
		FA30		JP	sectran		;sector translate

FFFF					Top of 64k Memory

 

 

I'll add more as I get it together.  While I don't think I need anywhere as much detail, I figure a compilation sort of like Mapping the Atari is the goal. 

 

 

 

1 hour ago, reifsnyderb said:

 

0000			Start of Memory
	0000		Low Storage	System Buffers & Parameters
		0000	Jump to BIOS		(JMP FA00)

 

Note that when the machine is powered on, 00000H reads JP BOOT, but the BOOT code changes that to JP WBOOT. It's used by programs that overwrite CCP during operation because they need more RAM. The general approach to detect the amount of RAM is to check location 7 (the high byte of BDOSE, BDOS Entry point) and use that as the top of the RAM. Normally a program exits with RET to CCP, but if it knows it has overwritten CCP or modified important disk structures on disk, it does JP 00000H, which does a warm start, which reads CCP from disk, and initializes itself again.

  • Thanks 1

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 atsysgen.com atformat.com atbios.com some boot sectors.atr

  • Like 2
  • Thanks 1
1 hour ago, kheller2 said:

Are these binary files intact and not missing line feed characters?

Binary files don't have line feeds. They look to be extracted from the binary blob hexdumps in CPMFILES*.MAC, which was actually on my todo-list :) Not sure if he used the CPM1 or CPM2 directory version. Files from May 30 1984 (sizes 117148, and last one 49948) are identical though, so I that doesn't matter.

 

The atbios.com file is not a real CP/M COM file (which would load at 00100H) but a memory dump from 00000H-0F4FFH. The BIOS is re-assembled at F200. A bit low, but at least there's plenty of room for the command frame ($fbf0) and data transfer area ($fc00). The rest is padded with zeroes. I compared it with the 20K version at 04A00H and it seems it not just a re-assembled file. I'll run the disassembler on it to see what's changed.

 

Edit: 20K version at $4a00

 

Edit2: it actually is identical to the 20K version, just reassembled to $f200 with CCPSTART at $dc00 and BDOS at $e400 (BDOSE = $e406). I don't see CCP.SYS and BDOS.SYS at these locations anywhere, but they are easy to re-assemble from the Digital Research Inc. source code.

Edited by ivop
Posted (edited)
1 hour ago, ivop said:

The atbios.com file is not a real CP/M COM file (which would load at 00100H) but a memory dump from 00000H-0F4FFH. The BIOS is re-assembled at F200. A bit low, but at least there's plenty of room for the command frame ($fbf0) and data transfer area ($fc00). The rest is padded with zeroes. I compared it with the 20K version at 04A00H and it seems it not just a re-assembled file. I'll run the disassembler on it to see what's changed.

The purpose of this "data transfer area" is something I do not understand why Atari did this.  Why not just put the data exactly where it belongs? 

 

i.e.  A request is made through the CP/M BIOS.  Let's say it's a read sector.  So, the CP/M BIOS puts the right data in a data structure (or frame) and sets the service request signal high and waits.  The Atari sees the service request, stops the Z-80 CPU (BusReq and BusAck), reads the sector, and puts it in the exact address specified by the CP/M BIOS DMA Address.  (The DMA Address is supposed to be set by CP/M anyhow.)  Obviously, due to banking reasons, the Atari has to translate the 64k DMA address into the bank and address from $4000-$7FFF.  (Big deal.)  Finally, the Atari sets a byte to tell the CP/M BIOS it's finished and sets BusReq high.....thereby re-starting the Z-80 where it left off.

 

This would save CPU cycles due to not having to transfer the data from this data transfer area to it's final location.

 

I don't know why Atari did this.

 

That all being said, I am exploring a re-write of the CP/M BIOS and using the decompiled BIOS as a reference.  Also, I've been using the CP/M "Alteration Guide" which goes into the BIOS in detail.

 

I've found some other things of interest.  For example, the CP/M BIOS allows for "sector skewing".  I've interpreted this description to be the same as setting an interleave factor for accessing floppy disk sectors.  (It appears to be the same thing.)  However, the CP/M BIOS "Alteration Guide" does specify that it's optional.  Since a 1050 would be used, and the 1050 is accessed directly by sector number, why not just skip the sector skewing and go strictly by sector number?  I need to double-check but I also think it's quite possible to put the sector number into the CP/M track field, and consider the disk to have 720 128 byte tracks.  The floppy disk access is next on my list, anyhow.  I think I've got the console I/O and printer I/O figured out.

 

Here's the current progress:

(Some subroutines are not finished, such as boot, wboot, and floppy access related subroutines.)

 

Edit to add:  My indents do line up in Notepad++.   😕

 

 





; CP/M BIOS for Atari 1090XL
;  Written by Brian E. Reifsnyder



; Notes:






; Page Zero Addresses
CBIOS			equ		$0000
IO_BYTE		equ 	$0003
DEF_DRV		equ		$0004
CBDOS			equ		$0005
BIOSTemp	equ		$0040		; 16 bytes



CCP				equ 	$e400
BDOS			equ		$ec00




DIRBUF				equ		$FF00								; 128 byte directory buffer

;	IO Structure
IOStructure		equ		$FF80
IOComplete		equ 	IOStructure + $00			; $FF on entry and $00 when complete
IOStatus			equ		IOStructure + $01			; $01 if successful, higher numbers are Atari error codes
IOCommand		equ		IOStructure + $02			; IO Command as per table
IODevice			equ		IOStructure + $03			; Devices as per devices table, below
IOSector			equ		IOStructure + $04			; Disk drive sector
IODMA				equ		IOStructure + $06			; DMA address for data transfer
IOByte				equ		IOStructure + $08			; Byte for console I/O or printer.


;	IO Commands
ConsoleStatus		equ		$00
ConsoleInput		equ		$01
ConsoleOutput	equ		$02
PrinterStatus		equ		$03
PrinterOutput		equ		$04



;	Devices:
;	Atari:			CP/M
;	E:				$45		("E")
;	K:				$4B 	("K")
;	S:				$53		("S")		
;	P:				$50		("P")

;	D1: - D4:	$00-$03
DeviceE		equ		$45
DeviceK		equ		$4B
DeviceS		equ		$53
DeviceP		equ		$50





; Subroutine Jump Vectors
ORG $FA00
	jp BOOT					; Cold start
	jp WBOOT					; Warm start
	jp CONST					; Check for console character
	jp CONIN					; Console input -- single character
	jp CONOUT				; Console output -- single character
	jp LIST						; Printer -- single character output
	jp PUNCH					; Write character to punch device -- Not needed
	jp READER				; Read from reader device -- Not needed
	jp HOME					; Move to track 0 on selected disk
	jp SELDSK				; Select disk drive
	jp SETTRK				; Set track
	jp SETSEC				; Set sector
	jp SETDMA				; Set DMA address
	jp READ					; Read 128 byte sector
	jp WRITE					; Write 128 byte sector
	jp LISTST					; Return printer status
	jp SECTRAN			; Sector translate subroutine -- Not needed?
;	jp NONSTD



BOOT:
	; Set service request flag to $00;
	ld	a,$00
	out ($00),a
	; Display signon message

WBOOT:

	; Load BDOS
	; Load CCP
	; Set CBDOS
	; Set CBIOS to jump to WBOOT
	; Set IO_BYTE
	; Select drive A in register c


	jp BDOS



; Console Status
CONST:
	; Returns $ff in register a if a character is ready to read, returns $00 if no character
	; Atari will check CH and set IOByte to $00 if CH is $FF.  IOByte will be $ff if CH <> $FF

	; Set IOCommand
	ld	a,ConsoleStatus
	ld	(IOCommand),a

	call	AtariIO

	; Return IOByte in a
	ld	a,(IOByte)
	
	ret


;	------------------------------------------------------------------------------------------------------------------
;	Console Input
CONIN:
	; Read the next console character into register a.  Set bit 7 (parity bit) to 0.
	; Will wait until character is available.

	; Set IOCommand
	ld	a,ConsoleInput
	ld	(IOCommand),a

	call AtariIO

	;	Return console character in a
	ld	a,(IOByte)
	
	;	Set bit 7 to 0
	and 	$7F
	
	ret


; 	------------------------------------------------------------------------------------------------------------------
;	Console Output
CONOUT:
	; Send the character from register c to the console output device.  Bit 7 is set to 0.
	ld	a,c
	
	;	Set bit 7 to 0
	and 	$7F
	
	ld	(IOByte),a

	; Set IOCommand
	ld	a,ConsoleOutput
	ld	(IOCommand),a
	
	call AtariIO
	
	ret



;	---------------------------------------------------------------------------------------------------------------
; Printer Output
LIST:
	; Send the character from register c to the printer.  Bit 7 is set to 0.
	; Send the character from register c to the console output device.  Bit 7 is set to 0.
	ld	a,c
	ld	(IOByte),a

	;	Set bit 7 to 0
	and 	$7F

	; Set IOCommand
	ld	a,PrinterOutput
	ld	(IOCommand),a
	
	call AtariIO
	
	ret


;	---------------------------------------------------------------------------------------------------------------
PUNCH:
	; No function
	ret


;	----------------------------------------------------------------------------------------------------------------
READER:
	; No function.  Return ASCII control-z ($1A), in register a, as EOF.
	ld a,$1A
	ret


;	----------------------------------------------------------------------------------------------------------------
HOME:
	; Set sector 0?


;	----------------------------------------------------------------------------------------------------------------
SELDSK:
	; Set disk drive.  i.e.  0=a=D1:, 1=b=D2:, 2=c=D3:, etc.


;	-----------------------------------------------------------------------------------------------------------------
SETTRK:
	; Actual sector number 1-720 ???


;	------------------------------------------------------------------------------------------------------------------
SETSEC:
	; Sector number is BC  (is sector number needed?)


;	-------------------------------------------------------------------------------------------------------------------
SETDMA:
	; DMA address in register bc.  b is high byte and c is low byte.
	ld 	l,c
	ld 	h,b
	ld 	(IODMA),hl
	ret


;	---------------------------------------------------------------------------------------------------------------------
READ:
	; Reads a sector into DMA address.  Uses selected drive, track, and sector.
	; Returns 0 in a if no error and > 0 if error occurred.


;	------------------------------------------------------------------------------------------------------------------------
WRITE:
	; Writes a sector into DMA address.  uses selected drive, track, and sector.


;	-----------------------------------------------------------------------------------------------------------------------
LISTST:
	; Returns the status of the printer in register a.
	;  a = $00 if not ready and $ff if ready.

	; Set IOCommand
	ld	a,PrinterStatus
	ld	(IOCommand),a

	call AtariIO
	
	ld	a,(IOByte)
	ret








SECTRAN:
	


	ret






AtariIO:
	;	Set IOComplete flag to $ff
	ld	a, $FF
	ld	(IOComplete),a

	; Raise service request flag
	ld	a,$80
	out	($00),a

	; Wait for IO to be completed.  (IOComplete will be $00)
AtariIO1:
	ld	a,(IOComplete)
	cp	$00
	jr		nz,AtariIO1
	
	; Lower service request flag
	ld	a,$00
	out	($00),a
	
	ret






 

 

 

 

 

Edited by reifsnyderb
  • Like 1
32 minutes ago, reifsnyderb said:

The purpose of this "data transfer area" is something I do not understand why Atari did this.  Why not just put the data exactly where it belongs? 

 

i.e.  A request is made through the CP/M BIOS.  Let's say it's a read sector.  So, the CP/M BIOS puts the right data in a data structure (or frame) and sets the service request signal high and waits.  The Atari sees the service request, stops the Z-80 CPU (BusReq and BusAck), reads the sector, and puts it in the exact address specified by the CP/M BIOS DMA Address.  (The DMA Address is supposed to be set by CP/M anyhow.)  Obviously, due to banking reasons, the Atari has to translate the 64k DMA address into the bank and address from $4000-$7FFF.  (Big deal.)  Finally, the Atari sets a byte to tell the CP/M BIOS it's finished and sets BusReq high.....thereby re-starting the Z-80 where it left off.

 

This would save CPU cycles due to not having to transfer the data from this data transfer area to it's final location.

 

I don't know why Atari did this.

Me neither. I guess they were just lazy and let the Z80 copy it to the right place.

32 minutes ago, reifsnyderb said:

That all being said, I am exploring a re-write of the CP/M BIOS and using the decompiled BIOS as a reference.  Also, I've been using the CP/M "Alteration Guide" which goes into the BIOS in detail.

 

I've found some other things of interest.  For example, the CP/M BIOS allows for "sector skewing".  I've interpreted this description to be the same as setting an interleave factor for accessing floppy disk sectors.  (It appears to be the same thing.)  However, the CP/M BIOS "Alteration Guide" does specify that it's optional.  Since a 1050 would be used, and the 1050 is accessed directly by sector number, why not just skip the sector skewing and go strictly by sector number?  I need to double-check but I also think it's quite possible to put the sector number into the CP/M track field, and consider the disk to have 720 128 byte tracks.  The floppy disk access is next on my list, anyhow.  I think I've got the console I/O and printer I/O figured out.

Sector skewing is not used. The table is a dummy. On a real 8080/Z80 it is used to to translate sector numbers for the drive controller, but that's not used here.

 

I wouldn't remove the track/secnum distinction. Multiply by 18 on the 6502 is cheap (*16+*2, just shifts and one addition). CP/M-65 internally doesn't use track numbers, and sector numbers range from 0-719 on a SSSD disk. In my 8080 emulator I translate track/sec to just sec for CP/M-65.

 

32 minutes ago, reifsnyderb said:

Here's the current progress:

(Some subroutines are not finished, such as boot, wboot, and floppy access related subroutines.)

 

Edit to add:  My indents do line up in Notepad++.   😕

If you are going to rewrite the BIOS anyway and not use Atari's stuff, IMHO it can be done much simpler. Jump table has every entry vector to almost the same Z80 subroutine. That subroutine does:

 

* call subroutine, saves Z80 registers at $ff01 and further (AF, BC, DE, HL)

* set $ff00 to BIOS call number (this is the only thing that is different for each vector)

* call Atari

* call subroutine, restores Z80 registers from $ff01 and further

* RET

 

Now you can just implement everything at the Atari side. You could leverage much of the i8080 emulator. You could either run it on top of CP/M-65 or copy the BIOS translation code and the relevant parts of atari800.S BIOS and run it independently.

 

Edited by ivop
  • Like 2
3 hours ago, ivop said:

Binary files don't have line feeds. They look to be extracted from the binary blob hexdumps in CPMFILES*.MAC, which was actually on my todo-list :) Not sure if he used the CPM1 or CPM2 directory version. Files from May 30 1984 (sizes 117148, and last one 49948) are identical though, so I that doesn't matter.

  Binary files certainly have that character in their code. I understand it’s not a text file.  But binary files have the letters A and I and e etc.  I just wanted to make sure that whatever damaged the “text” files didn’t also remove that byte from the binaries. 

18 minutes ago, kheller2 said:

  Binary files certainly have that character in their code. I understand it’s not a text file.  But binary files have the letters A and I and e etc.  I just wanted to make sure that whatever damaged the “text” files didn’t also remove that byte from the binaries. 

I understand what you mean. Thanks for your concern. The hexdump files did have missing line feeds, but the contents of the .Byte data statements are all there. See for example CPM1/CPMFILES1.MAC.3. The CPMFILES*.MAC files contain a dump of the CP/M filesystem, starting at track 3 (skipping the reserved tracks 0-2). If you were to convert the first 128 hex bytes to ASCII you would see the directory there.

  • Like 1
13 hours ago, kheller2 said:

Are these binary files intact and not missing line feed characters?

I got these from the LDA files. So no text in them, therefore no missing line feeds.

Took a bit of head scratching as to what is going on with them but managed to figure them (mostly) out.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...