drac030

This! Definitely! It is my main objection against rev. E/F: these are excellent stuff in themselves, but an upgrade from rev. D and spinning-platter HDD is not possible. Even worse if one wants to upgrade the interface but also wants to keep the spinning-platter media. Therefore adding a header for a 2.5-inch HDD would be a major improvement IMHO.

It is good that at least the COPY.COM reads the manual.

In this case COPY should eventually abort with error 182 "Path too long".

Rev. S (or D/S) is D with one-channel Covox. I think rev. E and F have the Covox by default. As for the licensing and stuff, I certainly have nothing against it. I would however prefer to retain the rights to the IDE+BIOS so that I could still modify the sources at will and release updated binary versions from time to time. To my understanding, the physical storage may be the problem. Up to (and including) rev. D the IDE+ interface was primarily designed for the spinning-platter IDE drives. These are becoming rare, especially 2.5-inch drives of reasonable capacity (like 2 GB rather than 200 GB). As of rev. E the hardware switched to CF cards, which unfortunately are becoming rare (and pricey) too. I personally have no problem with spinning-platter HDDs, when the one I use daily goes down, I still have two replacement drives in my drawer. But getting new ones on the market may be difficult.

It says: CPU TYPE: 65816 OS TYPE : RAPIDUS OS HIGH RAM: PRESENT Just a remark: on Rapidus OS programs do not need to scan for the High RAM, because the OS provides this information: PEEK(590) returns the number of additional 64k segments past the first 64k (0 = no additional memory, $FF = 255 additional segments for the total of 16 MB). PEEK(589) returns the most significant byte of the lowest address of the first detected High RAM segment ($01 = $010000). Also, kmalloc($FFFF) will return the total amount of High RAM free, kmalloc($FFFE) - the size of the largest free block. Any other value passed to kmalloc() will attempt to allocate the requested amount of pages and return the address on success. Under SDX, when 65816.SYS is loaded, the MALLOC() call with requested memory index 3 will allocate the High RAM, or return errors if not present. The relocating loader will use that call to allocate the High RAM and load stuff into it.

@kheller2 Thanks a lot. This mostly agrees with my guesswork I did years ago: http://atariki.krap.pl/index.php?title=Format_AtariDOS_3&redirect=no although I can see now that I got one or two things wrong then. Well, indeed, but, since a block is 1024 bytes, one could expect this number to be in the range 0-1023. But in fact this is low 16 bits of the file's size in bytes. I mean our traditional terminology, where 810 is single density, 1050 is dual/enhanced/medium density, and "double" is MFM with 256 bytes per sector (or possibly more). Not the FDC vendor terminology, where FM = single and MFM = double density. One more bonus way to crash the DOS 3 DUP: 1) boot with BASIC on 2) when READY appears, do POKE 82,1 3) type "DOS", press Return 4) in the DOS menu, select "F" Also, it seems that "Init disk" (and perhaps some more functions as well) does not work, if you have not listed a directory at least once after a boot.

1) What is the purpose of sectors 10-15 on a DOS 3 disk? 2) What is the exact definition of the first directory entry? 3) What is the meaning of the bits in the status byte of a regular directory entry? 4) Is there any provision for double density disks? 5) Any other special entries in FAT (sector 24) besides $FD, $FE and $FF? (EDIT) A bonus way to crash DOS 3 DUP: a) boot DOS 3 with BASIC on b) when READY appears, do POKE 82,0 c) type "DOS", press Return.

The "v16" version (post #5) runs fine from SDX. The earlier one I did not try. In U1MB one probably has to select a 130XE-compatible RAM extension (Compy Shop 320k or 576k). The program runs fine on 65C816 and Rapidus OS, and even with acceleration. As of 7 MHz the FPS indicator seems to go nuts, though.

I have no idea how SIO2IDE works (never had one), nor what problems you experience, nor what SDX version you are using.

Actually, it is. Doing something blatantly against the rules and reason is one sure fire way of getting attention on the internet and otherwise. This is why, for example, in the academic world any stupid publications are customarily ignored. Otherwise publishing (at own expense) a book containing nonsense would be the best way to get a lot of citations (thus improving its author's Hirsch index), because everyone else would rush to quote the nonsense in order to refute it.

He said that: He wants attention.

Hehe, I just took a look: lib_cfg\atarixl_small.cfg: #Code used for loading MEM.SAV, shouldn't be needed by a cc65 program. MEMSAVM_: file = "memx1.bin", define = yes, start = $15A4, size = $015C, optional = yes; @Harry Potter you do not really believe what you have been told (that $15A4 is the address of the binary loader in DOS 2.0), nor what you saw yourself with your own eyes (viz. that the program built with these settings, no matter how simple, does not work), right?

Altirra debugger in 65C816 mode, history window: It is "Timestamp format -> Show cycles". But the cycles it seems to show are slow bus cycles (aka 1.77 MHz cycles), even when the CPU is set to 20 MHz. Fixable? Also: could it remember the selection?

That sounds like an overstatement

It is 65XE with ECI. Pictured: Perfectly. I use it for programming, i.e. hours-long sessions of editing the source, saving to HDD, assembling, reloading the source code, editing again etc. I would not do that on unstable machine to avoid the risk of losing/screwing the sources. Even earlier I had a 10 MHz prototype. Later the 14 MHz one. Yet later (about 2014) a 16 MHz one. After that, the first 20 MHz prototype. The photo shows the second 20 MHz prototype. I also have a production board (partly visible on the right). I use the proto with an experimental 40 MHz core (unfortunately, not compatible with the production boards for a reason). EDIT: the computer works in turbo mode by default (like 99,99% of its time). But never had problems in Classic mode either. Thanks, I surely hope so too!

The firmware in the sense of "ROM software": FLND6502 v.1.1, MROM v.1.2 (MODULE.ROM only), Rapidus OS 2.43, these are the latest revisions. The firmware in the sense of "FPGA core": the production core 6S9054E is still the latest one and there are hardly any chances for a newer revision, I am afraid.

PBI #0 is hardwired to Rapidus. This may only be a problem if you use any other PBI device (like IDE+ for example). In this case the external PBI device should get configured to release the PBI #0. The BIOS/menu: the earliest version I have here is dated 15 Nov. 2016. But indeed, the production Rapiduses were shipped with slightly earlier version, date 29 Sept. 2016. I have no idea, why. In any case, the differences between the 2016-revisions are probably minor - what they exactly are, I do not remember, it has been 6 years.

There is an error there, though: the table on page 33 lists the 192k extension as RAMBO, without separate ANTIC access. Maybe such extensions exist too, but the whole point of using bit 6 in 192k for banking is to keep bit's 5 function of controlling separate ANTIC access. So it is not RAMBO-type.

The overlap is not a big problem, most RAM testing procedures are aware that some extensions have this "feature" (e.g. 256k already mentioned), for example: http://atariki.krap.pl/index.php/Obsługa_standardowego_rozszerzenia_pamięci_RAM The overlapping banks are skipped (so that a program trying to use the extended banks will not accidentally pull out the carpet from under its feet, so to speak). The procedure should still be put outside the area which can be possibly swapped out. In general, this is a nuisance rather than a useful feature IMHO. Also, using PORTB bit 0 to swap banks is certain to cause incompatibilities, because programs expect the ability to swap the OS ROM in/out regardless of the state of the remaining PORTB bits, and, conversely, that doing that does not switch the extension bank which has already possibly been selected and swapped in. That is why the extensions to 2 MB are not in use, although they were designed in the past.

It does not crash. Nor "modifying" the MEMLO is the problem. SDX tries to prevent programs from overwriting the system (the "Cubbyhole optimization" fellowship & consortes). Everything between $0700 and MEMLO is considered the system, thus if a binary file tries to load a segment into that area, it gets shot down mid-loading with "179 Memory conflict" error and the system returns control to the shell. Here the MSBASIC sets MEMLO first to $6A00, then tries to load itself between $1E00 and that. Since the MEMLO points to $6A00, the loader thinks everything below are resident system components, and therefore does not allow loading.

"Mine" is actually yours. I only applied few amendments, among which the most important (for me at least) is the one which makes it run under SDX

Yes, the version I posted above (in post #15) has that tail already cut off. Also the writes to $41 have been eliminated.

I think these can be safely removed, especially that crap's at the end only purpose seems to be just obfuscating things, if I am not mistaken. This could be moved to the end, just before the last init, perhaps; otherwise the binary does not load in SDX. The result of the operation: MSBASIC.EXE This one loads under SDX and appears to run:

IMHO the best is to start programming as on 6502, then gradually get used to new features. I can observe that the thing which perhaps is most challenging are the variable-size registers: if the program does not work while it "definitely" should, then it is almost certainly the register size set different than expected in a place. It takes some time to get used to that. Therefore it is best to start off with some default size selected for the entire program, and change it only for particular tasks (subroutines), until remembering what is currently selected becomes automatic. New ELSA version on my site, by the way.

Error 160 is "invalid drive number". My guess is that not enough buffers have been declared to handle more than drives D1: and D2: (yup, it is not SpartaDOS, which handles this automatically).