Jump to content

drac030

Members
  • Content Count

    1,874
  • Joined

  • Last visited

  • Days Won

    1

drac030 last won the day on July 26 2016

drac030 had the most liked content!

Community Reputation

850 Excellent

1 Follower

About drac030

  • Rank
    Stargunner
  • Birthday 07/28/1970

Contact / Social Media

Profile Information

  • Gender
    Male
  • Location
    Warszawa, Poland

Recent Profile Visitors

17,656 profile views
  1. Is this supposed to be Axlon-compatible? If so, insert the SpartaDOS X cartridge, if you have one, power up the machine, then type MEM (or MEM /X) at the DOS prompt and see what it says.
  2. I have uploaded an updated version. Many thanks to the brave souls who actually tried the program, and especially to those who shared opinions.
  3. Just check if the disk's capacity is really 720 KB after that. Just recently I had a chance to play for several hours with one of these drives, and in seemingly identical configuration: XF551 + 3.5-inch floppy drive, by Zaxon. All was fine except that the drive did not really format the diskettes to 720k, when told to do so, just 360k. EDIT: it must be added, that this behaviour is unfortunately pretty common in disk drives, i.e. accepting impossible geometries then returning no errors whatsoever neither on that nor on the subsequent format command. I remember that my TopDrive 1050 was happily buying 80-track SSDD geometries, but the floppy really was of course formatted to a 40-track SSDD. Also, the firmware in the XF drive I was dealing with did not handle the PERCOM commands correctly: the WRITE PERCOM was accepted (hence there was no problem in formatting floppies to whatever density was selected), but the READ PERCOM always returned the geometry for a SSDD-formatted disk (180k). The symptom of that is that the SDX 4.4 formatter complains about invalid parameters when e.g. 360k formatting is being ordered...
  4. CP/M 2 maps files keeping a list of "blocks" (= clusters in MS-DOS terminology) as a part of the directory entry. When an entry is full (it can keep a number of blocks enough to store 16k of the file's data), the BDOS creates another directory entry for the same file and saves additional block numbers there. And when this one is full too, yet another entry is created and so on. When one takes a look at the file systems which were in use in 70/80s, the SDFS really looks sane, clean and efficient
  5. The most stupid idea was IMHO not the sector link itself, but using its 6 bits as "file number". This not only reduces the max. number of files on disk to 64, but also reduces the overall capacity of a disk to 1023 sectors (with 24-bit link!). This is a bit wasteful, I would say. It could be for example 16-bit links used in more efficient way: say 1 bit for the end flag (if set, the last byte contains the number of bytes in the sector), 15 bits for the link = max. 32768 sectors, 126 data bytes each = ~4 MB, the number of files per disk virtually unlimited... Or bidirectional list, 124 data bytes per sector * 32768 = still more than 3.8 MB, instead of just ~125k. To be fair to them, it could have been worse: the filesystems on the competing platforms (CP/M 2, Apple, CBM), as far as I know, do not even allow to detect EOF reliably, if the file itself does not contain some information on that (file's size in the header or an EOF character at the end). On Apple the DOS uses physical track and sector on track numbers to address the files on disk, LOL. (CBMFS on Commodore also uses physical sector addresses, but the DOS is in the disk drive, so it is not a problem).
  6. This FS is overly simplicistic and lacks everything, but has one advantage: you need only one buffer to access a file (SDFS needs two, so does FAT and such). Also, as far as I know, CBMFS in the 1541 drive for C-64 uses similar approach, so DOS 1.0/2.0 method of linking files was not so exceptional at that time.
  7. It should work without the High RAM, just expect around 16k for the symbol table. Which should still be pretty much (about 1000 labels, if max. up to 6 characters each).
  8. Yes (thanks, mono), the download page is here: http://drac030.krap.pl/en-elsa-pliki.php
  9. If anyone here is interested... I have published ELSA, my (to this time) private assembler I have used to compile most of my programs: http://drac030.krap.pl/en-elsa-info.php Those who are familiar with MAE will feel at home. There is a PDF there (and a TXT file in the archive) which explains the details. I started writing it around 2006 and, as years were passing, it was taking over more and more of my projects. ELSA compiles are e.g. the Let's Emu! ZX Spectrum emulator, MultiBASIC, U-BASIC, Rapidus OS and such. The latest convert is IDE+ BIOS (which has grown so large that MAE started to run out of memory while assembling it). It is written in pure 65C816 native code, so it will run on Ataris with Rapidus and Antonia. Have fun
  10. Because this is a DOS 2.0 disk marked in the VTOC as MyDOS disk. Edit the sector $168, change the first byte from $03 to $02, save the changes - and voila, it will now be readable.
  11. This was not a false alarm: the BIOS is supposed to handle the rev. C as well. From the firmware's point of view, there are four versions of the IDE+ hardware: A/B/C, D, E and F. Selecting the proper code path was busted in one or two places and that is why it did not work with anything older than D. This below should work with rev. C. It only does not work with emulated rev. E, but on real rev. E it works, so I guess that the rev. E emulation may be somewhat inexact somewhere. bios17a.arc
  12. It is never too late. Now there is the Simple 65C816 Processor Adapter (DIY) http://hardware.atari8.info/65816.php, the Antonia (65C816 + up to 2 MB linear RAM - which less or more corresponds to the Turbo-816) and the Rapidus Accelerator. Really, more options than in the past, and truly more powerful.
  13. Your ATR is correct in itself. I booted it successfully from SIO (using RespeQt, at 57600 bps) and from a real HDD (IDE+ 32 MB partition). So the problem must be in the configuration of your SIO2SD. Maybe the serial speed you selected is still too high for SpartaDOS, try something like 52-57 kbps (POKEY divisor from 8 to 10). By the way, many programs you have collected on that ATR in the SD_UTILS directory are SpartaDOS X programs which will not run under SpartaDOS 3.2. For example: CONFIG, ECHO, INIDOS, KILLDIR, MDUMP, NEW, RUN, TOMS, TRACE, TTD, VIEW. Most of them is so old that I doubt if they could run even under modern versions of SpartaDOS X. And, by the way... Seeing KILLDIR.COM in there truly touched my heart. It was my first ever program written for SpartaDOS X (then version 4.20) with the use of the SpartaDOS X library calls and compiled into the native, relocatable SDX binary format. I still have the source code, it is dated 21 Sept 1993, which must have been the day I last touched it. Since there was no appropriate assembler which would allow to generate the relocatable binary (no Mads, not even Fast Assembler yet), the source code is named KILLDIR.M65 - yes, MAC/65. All the fixups and stuff generated as blocks of .BYTE data, plus probably a helper program (I do not have it) which fixed the header afterwards. We had no information on the SDX internals (nobody had, as far as I know), so all the stuff: that it is there, what it is, and how to use it, had to be gathered first by analyzing the binary code. The program lives until now, cleaned up, debugged, enhanced, renamed, compiled with Mads, but still the same: it is CAR:DELTREE.COM in the current SpartaDOS X distributions. MDUMP.COM is probably mine too, and I too still have the source: same M65 format, same stuff as above. And it is MDUMP.COM until this day (CAR:MDUMP.COM). Man, people were doing such stuff when the world was young
  14. The VGA cores required 28 MHz IIRC. Also the monitor itself may be pretty dumb and accept only its 72 Hz vertical sync / 36 kHz horizontal sync. I remember that even with Falcon030 video shifter, which is pretty flexible regarding the low level video settings, the only thing I could have done with SM124 was bumping the vertical resolution from 400 lines to something like 480 (or perhaps even 512, I do not remember). This was accomplished by lowering the lower border, the rest of video parameters were not tunable. But still, this perhaps was because it was just the legacy mode and they did not care to make it tunable (because admittedly who being sane uses Falcon030 with SM124?). So this still does not tell us much about the abilities of that monitor.
×
×
  • Create New...