ivop

I have seen some weird shipping routes, too. Got this package from China which after a day or two arrived in Luik/Liège, Belgium, which is very close to the Dutch border. But instead of hopping over the border by freight train, it first went to Paris, and then to Amsterdam. Both by plane

Oh, looks like I might have posted the wrong version If you look at dos2copy I do the same as David, i.e. compare with 0xff. Somehow I ealier posted a version from before I fixed this, but with the console output of the correct version. Here's the right version. 64k CP/M vers 2.2 A>write Opening file Setting DMA Filling buffer Writing buffer Closing file Done. A> write.zip

Try ERA FOO.BAR first. make_file() fails if the file exists. That's why dos2copy does a delete_file() first. Does that help?

Here's dos2tools for CP/M. Even though I prefer to use cpmtools myself, I acknowledge that the command line is not for everyone, so now you can download CP/M files, put them in a DOS 2.x formatted ATR with your favorite GUI tool and copy them to your CP/M disks from within CP/M. I implemented CP/M style wildcards which means you do not have to copy each file one at the time. Period ALL CAPS interface Compiled versions for the atari1090ed disk format, plus source and Makefile included. dos2tools.zip

I have used it myself, too. In midimon for example: https://github.com/ivop/midimuse/blob/master/software/midimon/cio.s That's actually the CIO macro library from the Atmas-II manual, converted to mads. If you don't need speed, it's indeed very helpful, and it's a quick way to get some messages on the screen.

I did a bit more in depth disassembly, and it turns out it is not the utility you are looking for. It just copies some sectors from drive x to drive y and is probably part of preparing a new bootable disk. We don't need that. The SYSGEN I supplied earlier will take care of that, and in case you decide to incorporate the .SYS loader, there's PIP to copy over bios.sys, bdos.sys and ccp.sys. But for now, SYSGEN is enough. So, a simple format utility is easy (send format command, fill bootblock with 0E5h). SYSGEN we have. Copying files from DOS 2.5 to CP/M is not what ATCOPY does, but it's fairly trivial to write. I'll write it this evening in portable C so we can use the same utility under CP/M-65. That was on my todo-list anyway, so that's two birds with one stone The author of the ACK CP/M backend is the same as the author of the llvm-mos CP/M-65 backend (David Given), so the API is nearly identical. atcopy.asm

Yes, that sounds helpful during debugging the Atari side of things. BTW WozMon Z80 actually is a thing. I googled it and found: http://www.welzel-online.ch/downloads.html . Source is included. Looks easy enough to replace the single board computer I/O with BIOS calls and include it in your BIOS. Then, triggering an IRQ could jump to there. Yes, it's the original DRI 8080 SYSGEN.ASM source code from '79. It has nothing to do with Atari. I just also named it ATSYSGEN because that is what it replaces after my modifications for your Atari ED format (3 tracks bootblock, 26 sectors per track).

Can't edit the previous post anymore. But I just tested the freshly assembled ATSYSGEN.COM under emulation and it works correctly with whatever number of bootracks and sectors per track I hardcode in the assembly source. It's a bit of a weird "conversation" you have with the program though: A>atsysgen SYSGEN VER 2.0 SOURCE DRIVE NAME (OR RETURN TO SKIP)a SOURCE ON A, THEN TYPE RETURN FUNCTION COMPLETE DESTINATION DRIVE NAME (OR RETURN TO REBOOT)b DESTINATION ON B, THEN TYPE RETURN FUNCTION COMPLETE DESTINATION DRIVE NAME (OR RETURN TO REBOOT) So you type 'a', then Enter. Then 'b', then Enter, and after that you can run it again on a different destination. If you don't press another drive name but Enter instead, it does a JMP $0000 and exits.

It doesn't really matter if it's 8080 or Z80 code as long as your disassembler is Z80. As a bonus, you get Z80 mnemonics instead of the horrific Intel 8080 mnemonics. I started disassembling atformat, and it does indeed send a special BIOS command to the Atari. For fun, I tried Ghidra in Z80 mode, but it does not have a proper export to assembly. I am expected to write code for that, which I'm not going to do. Reko constantly crashes, so I guess it's back to the z80dasm command line utility Perhaps it's easier to write format and sysgen from scratch. We can even do that in C and compile with the Amsterdam Compiler Kit. Format just needs to read the drive name from the command line (from cpm_fcb), ask for Y/N, and send the format command to the Atari. Sysgen is basically a sector copier that copies the bootblock from drive x to drive y, which is also trivial in C. An extent is the portion of a file controlled by one directory entry. There can be up to 32 extents to make up one file. If the disk size is <256 blocks, the allocation vector contains a maximum of sixteen bytes (block references) per extent. Otherwise it contains eight lsb/msb words (block references) per extent. Ah, IIRC that's a Z80 port of wozmon, isn't it? Is it small enough to fit in the BIOS? Edit: BTW the original 8080 SYSGEN.ASM is available. I'll look into what it exactly does and if it's enough to just copy the bootblock from one drive to another. Edit2: I think we can just use the standard SYSGEN.ASM. It has hardcoded sector skew translation, but that can be turned into a no-op with the right table. I think the 1,2,3...,26 table we use (I used the same in my 8080 emulator) is wrong though. It should be 0,1,2...,25 as the Atari counts from zero, like BDOS, and not from 1, like the MDS-800 floppy controller which most of DRI's default code is written for. Edit3: attached atsysgen.zip. Contains official DRI source, modified for 3 boot tracks and sectran to a no-op, and the resulting binary. atsysgen.zip

The AT* tools all run on CP/M, so I assume ATCOPY copies files from DOS 2 disks to CP/M disks. Compatibility with ED is handled by BDOS+BIOS. The dumps are not correct though. They include a zeroed page zero. I suppose if you cut of the first 256 bytes, they will work. I can run them through a disassembler if you want to. They are fairly small. The idea is that ATFORMAT formats a disk (that would have to be changed to ED, not sure how it signals the Atari to do the format command instead of R/W) and run ATSYSGEN to copy the bootblock to make a bootable "system" disk. BTW if you are running short on disk space in the bootblock if you add terminal handling and debugging capabilities, you might want to have a look at https://github.com/davidgiven/cpm65/blob/master/src/lib/loader.S . That's a small loader that knows just enough about the CP/M filesystem to load files (bios.sys, bdos.sys, ccp.sys) instead of including them in the bootblock, provided that 1) the file occupies exactly one extent, 2) it contains no empty blocks, 3) it's on drive 0, and 4) the file exists. If you decide to use that, you might even cut back on the number of reserved tracks to 2 or even 1. Re debugging via a Z80 interrupt. There's DDT.COM which you might want to overlay. It's a weird beast though, as it consists of multiple parts of which the first one is a relocator to upper memory, the second and third part are the actual program that gets relocated, and the fourth part is the relocation table. I recently setup a github repo that builds all of CP/M 2.2 from source with an ISIS-II PL/M-80 cross-compiler, an ISIS-II ASM80 cross-assembler, and a DRI ASM compatible cross-assembler. There was no native tool to generate the PRL (Page ReLocation) table, so I wrote a small utility to do that. The repo is here: https://github.com/ivop/cpm22-from-source Another possibility would be to run the debugger/monitor at the Atari side. You are basically a "Freezer" for the Z80. The only thing the Z80 IRQ handler should do is save its registers somewhere the Atari can read them. You could hide that small routine in the BIOS. That way you do not have to overwrite any (upper) memory with DDT or another monitor/debugger, which might conflict with the running application you are trying to debug.

What I really find annoying to disassemble is code like this: jsr PRINT .byte "Hello World!", $9b jsr PRINT .byte "Press any key", 0 rts PRINT: ; get PC from stack ; print string from PC+1 up to $9b or 0 ; put adjusted PC back on stack rts I understand it's convenient for the programmer, especially with a macro generating the jsr and .byte sequence, but having to manually flag tens of regions of memory as data gets tedious very quickly.

Nice! I briefly looked into this, and I noticed you introduced a Windows-only dependency for the colored text output. Perhaps you could just send ANSI escape codes instead so it keeps working on Linux, MacOS, etc.? Also, please only print fully formed escape sequences in one go, preferably even full "sentences" that end with the terminal in the original state, as currently it screws up the terminal during parallel builds (i.e. running multiple mads instances with make -j8).

https://www.linusakesson.net/software/sidreloc/index.php

Found another one. This time in the official DRI's XSUB (eXtended SUBmit): lda bdos+1 cpi 06h jnz loaderr Hopefully that one works okay!

That's disappointing. I just found this: Perhaps reading works well enough (with retries?) to make a copy to a real floppy? It needs extended memory, but I assume that's not a problem with your 1090 memory expansion