-
Posts
3,340 -
Joined
-
Last visited
-
Days Won
3
ivop last won the day on April 9 2017
ivop had the most liked content!
Contact / Social Media
- Website
Profile Information
-
Gender
Male
-
Location
The Netherlands
Recent Profile Visitors
22,727 profile views
ivop's Achievements
River Patroller (8/9)
4k
Reputation
-
Differentiating data from code on Assembler
ivop replied to lbaeza's topic in Atari 5200 / 8-bit Programming
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
-
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?)
-
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.