Atari 800 XL/XE Port #21
Conversation
|
Showing STAT and BEDIT behaviour:
The heart symbol is ATASCII zero.
|
|
That's great --- thanks! I was just thinking about doing this one; all I need now is an Oric port and I think I have coverage of the main 6502 microcomputer systems... Regarding the weird corruption: which version of llvm-mos-sdk are you using? I found and fixed an issue in elftocpm65 that was causing certain relocations to be computed incorrectly. One of the symptoms was asm producing bad code. It doesn't look like it's been released yet, so if you aren't using head from github, that'll be the problem: |
not exceed number of bdos sectors in atari800 BIOS, otherwise it needs to be adjusted manually (for now).
|
Thanks! I have compiled llvm-mos from source and installed the latest git HEAD of llvm-mos-sdk. It does improve a little. No more NUL characters, but it still doesn't correctly evaluate DSK:, VAL:, USR:, etc... STAT A:=R/O Does it still work at your end? I also noticed that REN does not work. REN DUMP.ASM=FOO.ASM I ran some traces and it appears that in entry_RENAMEFILE in bdos.S (param) points to FOO.ASM when it starts matching with all the directory entries. That seems wrong to me. It should point to DUMP.ASM. Perhaps CCP is doing something weird here? Besides the BEDIT bug, everything runs fine! TYPE, COPY, SUBMIT, no problems there. Once I/we got this STAT and REN problem fixed, I'd like to look into writing a better terminal emulator for the Atari. The E: (Editor) handler is not that bad, but it lacks positioning in the incoming data stream. I think ADM-3A would be the way to go as it is simpler and shorter than VT52/VT100 and was used a lot BITD if I understand correctly. |
|
I've just tried STAT, and yes, it doesn't work. (I only ever use it on its own or as STAT ., both of which work fine.) I'll take a look. I actually deeply dislike STAT and would like to get rid of it, but it's kinda iconic with CP/M. Regarding REN: remember the options are backwards --- it's Regarding BEDIT: you found a new bug! If loading a file fails, it doesn't terminate the file in memory. Loading an existing file, or creating a new file by just invoking BEDIT and then doing SAVE all work fine. #22 Regarding terminals: I actually have a plan for that. What I want is to introduce loadable device drivers, each of which implements a jump table modelled after the ones the BIOS and BDOS use. There will be a SCREEN device which provides a bunch of methods for basic screen manipulation (query screen size, clear screen, move cursor, draw text, erase area, read character, that sort of thing). Then there can be TTY devices, which can be platform-independent, which replace the BDOS's console entrypoints with a terminal state machine. These will use the SCREEN device. The SCREEN device itself can either be loaded dynamically or (more likely) embedded into the BIOS. The reasoning is that this will allow native applications to draw on the screen without all the pain of going through terminal escape codes, plus it's more flexible, plus it's easier to implement, plus it'll be a lot faster. If you want a terminal emulator you have a choice (ADM3a or VT52, I'd guess), but if you don't it's not using memory. Unfortunately this design largely exists in my head while commuting... |
|
Ah, REN has the arguments backwards. Thanks! It works now. Regarding terminals, I was also thinking of separating the platform independent parsing of the datastream and the actual drawing. Am I right to assume that BIOS entries are CP/M implementation dependent, and BDOS calls are independent and should always match? It's a pity the Atari only has 128 characters, so there's only 32 for graphics and ADM-3A needs 64. The C64 has 256 characters IIRC. |
could be booted on a 400/800 with 32kB RAM. If you forget to disable the BASIC ROM, it still runs, albeit with 8kB less RAM on a 48+kB machine.
* Update SD image to ATR. XFD is obsolete and is poorly supported by modern hardware drive emulators.
|
I brain dumped some driver stuff and how I think the screen and tty driver interfaces will look into #23. |
|
Fascinating! Looking forward to implement the Atari screen driver. Once a proper TTY is in place, that opens up a lot of new possibilities. BTW one non-Atari related bug was fixed on my branch. Commit 8954d25 fixes an off by one error which prevented CTRL-C doing a warm start. Currently I'm getting more familiar with the source code and writing a few small utilities. DINFO (drive info, 512 bytes), and LS (list files with proper file lengths). LS is currently in C and ~2kB, but I'm going to port it to native asm soon. Also wanting to make the Atari port somewhat RESET proof. That is, if the Atari RESET button is pressed, it does a lukewarm start by just restarting the CP/M BIOS. That avoids having to load BIOS/BDOS from disk again. I also ran it on real hardware this evening! I put the ATR file on a CF card, mounted it as D1: with a SIDE2 cartridge an booted it. Works perfectly fine :) And it's pretty fast because it doesn't do serial IO to a diskdrive, but reads it from the CF card through a PBI driver. |
Start with lower case keyboard input.
* cls - clear screen (if terminal supports ^Z) * dinfo - display information on current or specified drive * ls - display alphabetically sorted list of all or specified files
|
Update:
|
|
We can has drivers --- see #24. You'll need to update your BIOS to contain a TTY driver, as the generic code will always try to use it, but that should be trivial. Regarding reinvoking the BDOS: yes, that's tricky. You can't just reinit the BDOS because it'll try to claim its memory again. Modifying the BDOS to set its own vector seems like a sensible way to do it --- go ahead. Adding drives in CP/M is annoying, as each one needs its own bitmap, which all consume TPA. So for 15 drives you'll need fifteen bitmaps and DPHs. They can share a DPD and directory sector but the macro which generates all this isn't set up for that yet; I haven't gotten multiple drives working yet... and there's a known bug where if you type the wrong thing the BDOS will switch to drive 0 ( Let me know when things are in a reasonably stable state and I'll merge? Your code all looks fine. |
|
Wow, great. Nice job! I have updated the Atari port to the new driver model, and after I found out I missed the jsr initdrivers line it all works fine now. I consider my code in a reasonable state, so if you want to merge it that would be nice. As for adding extra drives, 15 drives would be overkill, but two SSSD Atari 810 drives on real hardware would be nice. I already noticed the DPHs and I assume that could grow quickly. My port currently builds two different ATR disk images. One 90kB disk (hence the MINIMAL_APPS in the Makefile) and one 1MB drive. The last version has 1 page less TPA. While I was looking to find out why it didn't work to switch to B: I noticed the following lines in bdos.S convert_user_fcb: Why is it writing the user number to fcb.dr? I also noticed something strange with the native assembler. If you look at my ls.asm code, there are three nops in there. If I remove them, the resulting binary does not relocate correctly and crashes. Any idea? |
blocksizes > 1024 bytes, too.
|
Merged! Regarding So CP/M has two very similar data structures; the FCB and the thing-which-has-no-name-which-I-call-a-dirent, which is the record on disk. These are very similar but not identical. In the FCB, byte 0 contains drive-plus-1 and there are the three extra bytes at +32 used for random access positioning. In the dirent, byte 0 contains the user number. So, You'll notice that the FCB doesn't have a field for the user number, which is why dealing with user numbers in CP/M is so wretched --- you have to remember to set the user number via BDOS_GET_SET_USER_NUMBER before every BDOS call or else the BDOS might create a new extent with the wrong user number and you'll lose part of your file. Some of the helper programs actually use a library working with things I've dubbed XFCBs which are an abortive attempt to patch around some of this, not very successfully. Unfortunately I can't think of any way to fix all this without losing compatibility with CP/M-80, for whatever that's worth... Re the assembler: I actually just found and fixed a bug, but it's not this one. Will look into it. |
|
Fixed in #26. |
Hi,
I spent the last eight hours creating an Atari 8-bit port. DEL=BS took me over an hour to debug ;) Oh well. It works now and it's pretty clean. I might do a 256-bytes per sector, larger disk (up to 16MB) ATR version later. Perhaps disable the OS ROM and do everything bare metal (TPA from $0200-$CFFF), but first I'd like the following problem to be solved:
I noticed that currently something is very wrong with STAT and BEDIT. I tried the beeb image (with b-em) and the apple iie image (with linapple) and both display the same behaviour. For example, plain STAT works, sort of, but prints a NUL character. Anything else, like STAT DSK: shows only a single line and some NUL characters. Similar, if I start BEDIT with a new file, add a line 10 Hello, and LIST, it shows garbage after the first line. The two might not be related though, as STAT is compiled C and BEDIT is assembly.
I used the latest versions of all tools, including the mos-llvm toolchain:
$ mos-cpm65-clang --version
clang version 17.0.0 (https://www.github.com/llvm-mos/llvm-mos.git b05db96bef682be2ead7d306bc430156912d2598)
Target: mos-cpm65
Thread model: posix
InstalledDir: /bigdata/llvm-mos/bin
Configuration file: /bigdata/llvm-mos/bin/mos-cpm65.cfg
The included assembler works BTW.
ASM DUMP.ASM FUBAR.COM
FUBAR FUBAR.COM
works correctly. See screenshot.
Kind regards,
Ivo van Poorten
Edit: And I couldn't get the C64 version to run. No idea why, but it hangs on Searching for CPM. That's with x64 (VICE).
Edit2: STAT FILE.EXT does show some more info, though.
BTW Forget to say thanks for starting this nice project! Thanks! Could become a time sink if I set my mind on it ;)