reifsnyderb Posted April 2 Author Share Posted April 2 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. Quote Link to comment Share on other sites More sharing options...
reifsnyderb Posted April 3 Author Share Posted April 3 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. 4 Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted April 3 Share Posted April 3 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? Quote Link to comment Share on other sites More sharing options...
reifsnyderb Posted April 3 Author Share Posted April 3 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. 2 Quote Link to comment Share on other sites More sharing options...
Geister Posted April 3 Share Posted April 3 Can the Z-80 card use the 80-column card for video output? It seems like that was meant to work. Quote Link to comment Share on other sites More sharing options...
reifsnyderb Posted April 3 Author Share Posted April 3 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. Quote Link to comment Share on other sites More sharing options...
Geister Posted April 3 Share Posted April 3 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. 2 Quote Link to comment Share on other sites More sharing options...
reifsnyderb Posted April 3 Author Share Posted April 3 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. 1 Quote Link to comment Share on other sites More sharing options...
Geister Posted April 3 Share Posted April 3 Yeah, I was kind of thinking about the SWP ATR8000 and how that could be a stand-alone computer. Quote Link to comment Share on other sites More sharing options...
Geister Posted April 3 Share Posted April 3 In any case, I can't wait to see what comes out of this. 1 Quote Link to comment Share on other sites More sharing options...
reifsnyderb Posted April 3 Author Share Posted April 3 New board renderings... 4 Quote Link to comment Share on other sites More sharing options...
Forrest Posted April 4 Share Posted April 4 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 3 1 Quote Link to comment Share on other sites More sharing options...
+kheller2 Posted April 4 Share Posted April 4 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. Quote Link to comment Share on other sites More sharing options...
reifsnyderb Posted April 4 Author Share Posted April 4 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. 2 Quote Link to comment Share on other sites More sharing options...
+DjayBee Posted April 4 Share Posted April 4 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: and then "No Syntax Highlighting" 1 Quote Link to comment Share on other sites More sharing options...
reifsnyderb Posted April 4 Author Share Posted April 4 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. Quote Link to comment Share on other sites More sharing options...
ivop Posted April 4 Share Posted April 4 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. 1 Quote Link to comment Share on other sites More sharing options...
sup8pdct Posted April 6 Share Posted April 6 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 2 1 Quote Link to comment Share on other sites More sharing options...
+kheller2 Posted April 6 Share Posted April 6 Are these binary files intact and not missing line feed characters? Quote Link to comment Share on other sites More sharing options...
ivop Posted April 6 Share Posted April 6 (edited) 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 April 6 by ivop Quote Link to comment Share on other sites More sharing options...
reifsnyderb Posted April 6 Author Share Posted April 6 (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 April 6 by reifsnyderb 1 Quote Link to comment Share on other sites More sharing options...
ivop Posted April 6 Share Posted April 6 (edited) 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 April 6 by ivop 2 Quote Link to comment Share on other sites More sharing options...
+kheller2 Posted April 6 Share Posted April 6 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. Quote Link to comment Share on other sites More sharing options...
ivop Posted April 6 Share Posted April 6 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. 1 Quote Link to comment Share on other sites More sharing options...
sup8pdct Posted April 7 Share Posted April 7 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. Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
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.