GoodByteXL

Besides SDX some other software is capable of keeping the ANTIC display running. BITD is used BobTerm up to V. 1.22 to 'browse' the BBS. This is my real CRT 80 monitor for Atari and alike. Recommended in the guides from Atari when using a XEP80 and still kept from the 1980's office times.

Of course there are a lot of other solutions to it than using Acrobat. Conversion from any graphic format to PDF is simple, as GIMP - available on all platforms for free - does the trick. And if you need to OCR your PDF, there are also many other good offers for it. Acrobat is simple to use but has a lot of disadvantages. Suggest to keep it in a loss free graphical format as most people use a sort of JPG, which causes always those ugly artifacts. This is what Acrobat does internally to imported graphics. You will later on never regain the original quality of a good scan.

It seems there is a issue with the used hardware. The XEX-file boots fine with RespeQt from SIO2PC-USB, loads from a SDX hard drive and also from a game-menu disk on RespeQt and from a real disk drive. mspac.atr

It's not worth to open up a new topic, but ... this should be corrected in the future: Cannot open '/DL_AA.atr': Unknown file type." is a misleading error message. It comes up when a partition/drive formerly used is not mounted when RespeQt ist started.

The 1986 version is Kyan Pascal V. 2.x. The KIX-prompt "%" identifies it. Additionally, type AS<RETURN> at the prompt to see the assembler version 2.x. Surfaced in Summer 1986. V.1 doesn't have an separate assembler - compiler and assembler are kept together in one program demanding more memory. That's why V 1.x requires an XL/XE. The 1987 version of Kyan Pascal 1.1 is a user modded version, as far as we could figure out. Last official version of KP 1.x was version 1.3 in late 1985/early 1986, which is not found yet.

It's not possible to answer as just a user. Another idea: If OSS language cartridges are plugged in, disable them as well if not needed. Very few programs do that actually though it's not a big deal.

The rest is already 'in use' -> in BASIC type: POKE 740,0:B.<RETURN> Start Memory Test - the missing 'blocks' already in use are shown in red.

Altirra works easy under WINE 'til V. 2.50 like a portable version. With V. 2.60 there was a change somehow and since then it needs to be run with higher rights (sudo) to be fully usable.

At least it exactly behaves as described in the manual: The root in that example from Level42 is considered to be the specified directory from which the COM files, if any, will be copied. So it works. Please look up the examples in the manual on page 51. Nevertheless it would be nice to have such a tool at hand to fetch the desired file types from the structure of a drive. But I guess it will get difficult depending on the size of the drive, the directory tree (as the path is limited to 63 chars) and, last but not least, the number of files. For example see the capacities of the MENU command to understand.

The switch '/R' causes COPY to recursively copy directories with their contents or the contents of a specified directory. It will not grab a specified file type from all subdirectories, as far as I know. If you put some COM-Files to your directory 'B:\' it will copy them but won't go deeper. It would be a nice feature tough.

Yes, and I sent you details in e-mails and described what is happening here and made a video to show you, what is not working. What more can I do to help to kill bugs? But all you responded with was a simple denial of my statements instead of testing it by yourself (at least you didn't write in your e-mails that you had tested what I described). I am neither a programmer nor a hardware developer, just a long time experienced A8 user. And my goal was to help to wipe off the obvious bugs from that project. But I guess my approach was understood as pointless criticism. In the meantime there is professional proof that I stumbled across bugs. With the help of tf_hh they are identified and described in the ABBUC forum. I recommend every user of that burner to study it thoroughly before trying to burn a 2732 EPROM. If you follow the guide lines there it works like a charm. If not following the hints the minimum problem to happen is that it is not working with 2732 types whereas 2764-27512 are programmed fine. The max problem that could occur is a damage of the burner. To state it very clearly: My goal was and still is to help to you to bring this burner as a re-imaged project back to the community. And despite lacking a lot of skills I put quite some effort into it, dug out the original manufacturer sources from the ABBUC archive, sent as much material as I could about the old burner I use and tested all the items from the old user guides to make sure it is most accurate before I started to develop an English version of it. As a thank you I received a complementary burner with two 2732 adapters from you and promised to test it with the goal to describe in the user guide which are the needs to know to successfully burn 2732 types with the new version of the burner and the original version using the second adapter. Thanks to tf_hh, who described the necessary work around to successfully burn, read and verify 2732 EPROMs with the re-imaged version, this is now possible and I will adapt it to the user guide in English and German. Last step will be to test it with the original burner and your adapter coming days. So let's blast the hardware and software bugs and make it to a perfect project from bits of the past.

And also a need to know: Additionally, there is a confirmed glitch in the software version 2.5: When doing read/verify of a 2732 EPROM just 256 bytes are processed and not the full 4096 bytes.

As far as I'm concerned AW80 was a mess to use. That's why I switched to Micromiser's TurboWord 80 back then running with SD2.3C. AW and AW80 were only used to write letters and such stuff as it was difficult to develop longer documents with it. Mini Office II, AustroText and TurboWord80 were much more capable and versatile, especially for users of other languages than English. I still keep a XEP80 for testing with SDX development. If there is anything special to find out I can set it up during Winter time and dive into.

There is some info missing still: The Mini Speedy was available in 3 versions. Speedy 'S' = High Speed Sector Copy in ROM, 'D' = BiboDOS in ROM, "DS" = BiboDOS and HSS Copier in ROM. So if it is a "DS" as on the pic above a switch helps to choose between DOS and HSS Copier. And, Compy Shop stated in the user guide that there are some 1050 not working with a Mini Speedy because of component tolerances in electronic parts and offered a service to check and fix it. HSS Copy can R/W with up to ca. 95,000 baud when the drive is in perfect shape. To exit HSS Copy press SHIFT-CONTROL-TAB together. Some other Compy Shop hard-/software reacts on pressing START-SELECT-OPTION together. In both cases a cold start will be executed.

As a member of ABBUC look up the respective special magazines folder: http://www.abbuc.de/mitgliedschaft/downloads/viewcategory/7-abbuc-sondermagazine I do not use google translate so I do not know if it comes up in English or any other language. If you look at the link without being signed in as a member of ABBUC, you'll find a probably a bit misleading text naming "spezielle Mitglieder". It should read "ABBUC-Mitglieder" as a membership is required.

Of course there is no proof unless a disk is found. But, as it was advertised and sold in 1984, disks containing files mainly carrying a 1985 time date stamp must be later revisions. That's what I wanted to point out. And another item to be recognized: Later versions of SD 1.1 are said to have a different volume name, V 1.1, whereas later revisions always show 'V 1.1+' If you browse older computer magazines from the US you'll find smaller (and older) ads from ICD in text mode with similar offers.

The SD 1.1HS from the SDCS 3.2 isn't the early version. A pic of the early version's disk directory is here.

Of course not.

Yes, of course I kept a full scan. The stamped serial number is 059442. Yes, that is noted on the respective pre-page and most likely covers the product development as a whole. The question however is, how many versions of the manual do exist. On what those "rarity estimations" are based is not clear to me. The first original version of SD(CS) I acquired was SDCS 3.2d and my hunt for earlier versions wasn't successful. At least we have to bear in mind that the official status date is "12/88". This leaves some things open as there are: - Were the printed manuals for V. 4,17 and 4.18? - Were there updates in form of "red sheets" for V. 4.21? - What was the real outcome of FTe's work done for V. 4.22 and is it documented somewhere?

And did you receive the red "Addendum Pages" with it? From what I collected over the years the history is: 4.17 ??-??-88 ICD 4.18 10-29-88 ICD 4.19 01-16-89 ICD (which is questionable to me as at least the time stamp on the manual is 12/88) 4.20 02-06-89 ICD 4.21 07-10-89 ICD 4.22 11-05-95 FTe From SD 1.1 I have never seen original packages though I browsed many flea markets and computer events for A8 collection purposes during our years in the US.

ehm, no - looking at the title of this thread it is about early versions of SpartaDOS. And SDX 4.19 is an early version looking at the current issue.

This is the same version, at least what I bought from ICD Europe. The paperback itself is more in a dusky pink whereas the cardboard wrap of the sales package was printed in purple/blue. The manual itself is V. 4.19, most likely the last printed version. To complete it to V. 4.20 a few pages printed on red paper were included covering the changes/add-ons. A few years ago I re-worked it into a complete manual available under legacy versions at the homepage of the SDX Upgrade Project. I have never seen the manuals issued with the early versions 4.17 and 4.18 or later revisions from FTe.

Alright, that makes sense. I'd wondered myself why it wasn't mentioned in the SDCS manual. They probably did update the SDCS disk later but not the manual. Good historical information. I bought the SDCS from ICD Europe in the late 1980's. It contained all SD disk versions from 1.1 to 3.2d. It came with the 1985 guide for 1.1 and 2.3 as the manual, and as "manual add on" the RTime8 Supplement which contained the latest developments for 3.2. An easy way to "update".

With mine it wasn't tape but foam rubber.

Hm, this is difficult to agree on as the "standard" set by Atari is to use PIA's Port B to address extended memory in chunks of 16 KiB, that's it. Thereafter other developers adapted that and designed memory extensions of different kinds following this idea for compability reasons. Though I use and prefer memory extensions providing separate access of CPU/ANTIC I have to realize that most memory extensions ever developed for the XL/XE line do not provide this feature. Therefore software making use of it is very limited. Of course one can use this option for programming, but shouldn't expect too much positive feedback when it comes to run it on real hardware.