ivop

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

Could you make a sector copy to a real floppy and try that? Edit: if you have only one real drive, you could boot from that, swap disks, and then press CTRL-C, assuming your CONIN routines passes along <32 characters.

I see. I'd forgotten about that as I always use SIO directly. I just noticed a bug in my CP/M-65 code. DDEVIC always needs to be set to $31, and SIO adds DUNIT to it. Well, they don't support multiple drives yet, so it never failed Back to your code. I assume write.com fails? After which command does it fail? (make_file, write_sequential, or close?)

Shouldn't that be JSR SIOV ? ($E459). You also need to set DBYTLO/HI to 128, and DSTATS data direction. You could basically copy most of my code from CP/M-65:

Here's a disk image that might help you debugging this problem Source: Expected output: Edit: BTW are you sure the disk is writable? I don't know what RespeQt's defaults are. Might be R/O. writetest.atr

Great! Just for fun, you could mount my sample bootdisk.atr as drive B: and do DIR there. Then try DUMP DUMP.COM And STAT DSK: Edit: and test writing to disk with PIP FOO.COM=DUMP.COM and then FOO FOO.COM

The 16 bytes are the ATR header. Also, the 79th sector starts after 3*26=78 sectors, which is 78*128=9984 bytes ($2700). With the ATR header, that's file offset 10000 (0x2710). From the bootdisk.atr that was made with mkfs.cpm and the diskdefs following your spec (boottrk 3):

You are not using the original DRI source code. BDOS starts with a six byte serial, and jmp BDOSE (the entry point) is after that. In a lot of versions it's just six zeroes, sometimes the second byte is 16H to indicate it's version 2.2 of CP/M. It's indeed used to find the BDOS entry for applications to call, but it's also used to determine MEMTOP (MSB used only), and sometimes to calculate the beginning of CCP. I have seen code doing a hardcoded BDOS vector - 00806H = start of CCP. For example The Amsterdam Compiler Kit (ACK) does that. Original code from January 1980: The original CCP source code has support for conditional assembly of it serial number: I used the vanilla sources to build CP/M for my 8080 emulator, and they are the same .SYS files I included in the cpm1090.zip file I posted here for you earlier. My builds are in the cpm22 directory in the atari8080 github repo. The original is here: https://github.com/brouhaha/cpm22/ . The only thing they did is convert it from the ancient 8080 ASM.COM format to something more modern. The assembler you need is linked to in the description. Edit: fixed to -00806H Also found the code in boot.s in ACK:

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.

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. 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 see. Googling around it seems they are harder to get than Z80s. So that's not a useful replacement either.

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. 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.