HiassofT

Not quite. Current stable is "Etch", the successor of Sarge. (security) support for Sarge ended March of this year. BTW: The easiest method to create packages for Debian Sarge (or any other Debian release) is to do it in a chroot. It doesn't matter if your main Linux is Debian, Fedora, Gentoo, ... as you have all needed programs/libs/... in a separate directory. The only requirement is that your processor is x86 compatible (32 or 64 bit mode doesn't matter). Just search for "debootstrap" (it's a perl-script) and then enter debootstrap --arch i386 sarge ./sarge-chroot After a little while you have all base files of Sarge in that directory and then can do a "chroot sarge-chroot", setup your /etc/apt/sources.list and start installing, compiling etc. so long, Hias

A lot of information has been published in the "Compy Shop Magazin". Here is a website with the speedy docs (in german). Ah, OK, I didn't know that before. So just forget about it, it's not that important. Thanks! I just downloaded it and had a first glance at the SDX examples. I guess it'll take some time until get familiar with MADS and SDX programming, but it looks very interesting. so long, Hias

They are already quite old, the current version (5.5) is from March 2005. But even older versions should be fine, too, I guess. Testing standard disk access should be working fine with WriteAtr. Just be sure to configure the drive as "360k" in the BIOS. You can also use MSDOS format.com to do a quick test. With fdutils/Linux you could easily check if formatting more than 40 tracks works, WriteAtr can't do that. But, back in the good old days, I used some other programs (can't remember their name) to format MSDOS floppies in higher capacity (more sectors per track, more tracks). Maybe a simtel mirror still has them. so long, Hias

Wouldn't it be possible to change the formatter so that it uses the standard screen memory instead of a fixed location? You could then just close and reopen #0 to clear the screen when exiting. But it's no big deal, there's a workaround (simply reset the speed table of the patch with shift+control+s just before formatting), and the SIO.SYS driver of 4.41 is also a lot better than the one from 4.1x/4.2x, so there's not much need for using a patched ROM. BTW: I'd really be interested in the procedure to create relocatable SDX modules. Do you have some documentation about this? According to Jindroush's list it should be $48 with DAUX1 set to $02 and DAUX2 set to $B0+driveno. I did a quick check and it was possible to configure the drive to D8: with it. Actually, you can configure the drive to an device ID, the happy software doesn't seem to do any checks at all. so long, Hias

Hi KMK, thanks a lot for all this in-depth information! This weekend I changed my code so that the $48 command is sent when a drive replies to $3f with a speed byte of $0a. This seems to be the cleanest solution to me. I'll do some more testing and then upload the new version later this week. Or you could also change the SIO.SYS to transmit a $48 after the $3f. Then Happy drives would work out of the box and the INDUS.SYS would only be necessary for Indus drives (and you don't need to include it in the default CONFIG). BTW, another SDX question: I did some tests and noticed that the FORMAT command of SDX 4.41 now uses the stack area to store screen data (4.22 used $0400). Was there a particular reason for this change, and could you move it back to $0400 or some other location? Then the new SDX should also work fine with the highspeed patch in ROM (and SIO2.SYS). so long, Hias

I just stumbeld across this thread, and, yes, this is quite easy in Linux if you have the "fdutils" package installed (it is included in the Knoppix boot CD/DVD). For example: format a disk double sided, double density, 9 (512-bytes) sectors, 42 tracks: superformat /dev/fd0 ds dd sect=9 cyl=42 "/dev/fd0" is the first floppy drive (A: in dos), use "/dev/fd1" for the second floppy drive (B:). Maybe you might also have to add a "tpi=48", but I'm not sure about this (I don't have a 360k floppy drive here in my PC). For a really quick test add options "-b 39 -e 41" to superformat, this only formats tracks 39-41. The full documentation of the fdutils is here: http://fdutils.linux.lu/Fdutils.html After you formatted the drive, you can try accessing it. First of all, the floppy device (/dev/fd0) acts like a standard file. So, to read the whole disk you could just do a "cat /dev/fd0 > imagefile". To write an imagefile, use "cat imagefile > /dev/fd0". If you have no data to write, use "/dev/zero" instead of imagefile, this will fill the whole disk with zero-bytes. Then, reading/writing individual sectors/tracks on the disk can most easily be done with the "dd" command. It lets you specify an offset where to start reading/writing, so you just have to know how to calculate this offset: - we will use a blocksize of 512, so the offset is just the sector number (starting at 0) - the first 9 sectors are on side 1, track 0, the next 9 sectors are on side 2, track 0. The next sectors are then at track 1 and so on and so forth. So, for example, the offset for the first sector on side 1 in track 40 would be 2*9*40 = 720. Now, lets write to this sector (we will just fill it with zeroes): dd if=/dev/zero of=/dev/fd0 bs=512 seek=720 count=1 And now read it back and write it to "imagefile": dd if=/dev/fd0 of=imagefile bs=512 skip=720 count=1 Note the difference ("skip" in reading, "seek" in writing). To write multiple sectors, just modify the "count=.." parameter. so long, Hias

Hi Andreas! Thanks a lot for the information, the Atari 8-bit FAQ also states that the TOMS and 1050 Turbo modes are compatible. But: an older version of the FAQ stated that the TOMS also supports Ultra Speed mode. It would be great if a TOMS owner could confirm whether this is true or not. If this is true, and the TOMS also supports the $3f command I might have to add a few lines of code so that, for example, the $48 is only sent when the speed byte returned is $0a. so long & thanks in advance, Hias

I might have found a solution. What kind of highspeed protocol do the Toms drive use? Is it this one? I don't understand polish, but it seems like this protocol is identical to the "1050 Turbo" mode. If this is the case, the code I wrote yesterday should be OK, as the 1050 Turbo mode is checked before testing for warp speed (with $48). So if the Toms doesn't respond to $3f, it should never receive a $48 command. so long, Hias

This would be a possibility, but unfortunately this would also break happy warp speed mode (commands 'p', 'w', 'r' at 38kbps) in my patch. First I check for the $3f command, then 1050 Turbo, then XF551 mode and at last I use a $48 command to check for happy warp mode. Yesterday I rearranged my code so that $48 is checked first, then $3f, and after that 1050 Turbo and XF551. But I guess I might have to change this again :-) Good question. I did some more tests and now I'm confused even more than before: The original "GTSYNC.COM" from the Indus Super Syncromesh disk just uses $58 commands to upload the syncromesh code to the drive. It doesn't send any $48 commands. The INDUS.SYS driver from SDX 4.22 first sends a $48 and then a $58 command. I also tried a config.sys with indus.sys enabled in SDX 4.41, but then I only heard some beeps but didn't get any log messages in AtariSIO (this is normal if the PC doesn't support the transmission speed). In a next test with SIO2.SYS (instead of SIO.SYS) plus INDUS.SYS again the $48 and $58 commands showed up. So, the big question here is: why does the INDUS.SYS driver send the $48 command? Do the Indus drives support it? I'd also be interested in such a list. Plus a list of the Indus commands. I only have various 1050s and a XF551 here to test, but no Indus/Toms/... drives. so long, Hias

Which of the commands is causing the troubles, the $48 (with DAUX=$0020) or the $58 (DAUX=$0119) and what are the issues with other drives? I'm also currently thinking about this. ATM I don't know of a way to reliably detect a Happy (except the $48 command). In particular this also means that my highspeed patch could misdetect a Toms as a Happy. BTW: Does the Toms $48 command transmit any data, or is it an immediate command like the Happy $48? I just thought about another approach: is there a way to identify a Toms drive (and maybe other drives that handle the $48 command)? If yes, we could first check this and then only send the $48 command if it's not a Toms drive (and hope that this check doesn't have any negative effect on other drives...). so long, Hias

Thanks a lot, now I also found it in the docs! BTW: I just finished implementing the new features (fast writes are always enabled for Happy drives, highspeed SIO can be enabled/disabled/reset with keystrokes plus another keystroke to cold boot the Atari) and started with beta-testing. If anyone would like to help beta testing, just send me a PM or email. so long, Hias

Another question: Which versions are this? I ran a trace and 3.2g, 3.3b and the new SDX 4.41 only send a $3f command to the drive, but not a $48. With SDX 4.22 it's the other way round, it sends just a $48 command (with DAUX=$0020), but no $3f. so long, Hias

Hi Ijor! Ouch, this is really bad :-( Do you remember where this was documented? I just have a copy of the "warp speed software rev 7 user manual" which doesn't contain any information about SIO commands at all. ACK, you are right. I'll extend my patch so that it will enable fast writes. so long & thanks a lot for the info, Hias

You can also easily patch a ROM on a Windows PC (using the patchrom.exe) or on a Linux PC (do a "make patchrom" first to compile the executable). If you like I can email you a pre-patched XL/XE ROM. The patched OS ROM works fine with SpartaDos (just ran a quick test with 3.2f and 3.2g). But, since SpartaDos doesn't use the SIO code of the OS (only for the first few sectors when booting), it doesn't really help much. With SDX 4.22 you can use the SIO2.SYS instead of the default SIO.SYS. Then you can also use highspeed SIO with SIO2PC/APE/... OTOH, the "software patch" won't work with SpartaDos if it uses the RAM under the OS. IMHO the best solution would be to take the source code and create a driver for SpartaDos out of it. I'm not really an expert in this area (actually, I don't even know how to do this) and also I don't know if it would be possible with SpartaDos 3.2x. But I'm sure there are others here that could answer the question and/or create a driver. BTW: the new SDX 4.41 already includes a working SIO.SYS driver that supports ultraspeed SIO with SIO2PC etc. so long, Hias

Hi Ijor! Thanks! I agree that would be a nice addition. One likely scenario where high-speed SIO capability could change dynamicly is with a Happy or other "programmable" drives. I checked the various MyIDE versions and think I found the right location to patch the code (replace the "LDA $D209" with a JMP to the new code). A first, quick test worked fine, now I have to do some more testing. Yes. What kind of problems are this and under which circumstances do they show up? I ran a some tests with my Happy 1050 (in ultraspeed mode and in warp speed mode and disks in ED and DD) and everything seemed to work well. I then sent a happy command ($48) with DAUX set to $0020 to the drive, writing then was of course faster but otherwise it worked as well as without this config. In general I don't like fiddling around with drive settings too much. First I'd have to check if such a command has negative effects with other drives and then I'd also have to be sure it works well with Happy drives. For example: what happens if the user first uploaded code to the drive's RAM? so long, Hias

Hi! I knew this question would come up :-) The current SIO patch doesn't support the Syncromesh mode, basically for 2 reasons: First, I don't have a Indus drive to test it. OK, this isn't a big problem, I just would need someone with an Indus drive to do the tests for me. But then, there's this big problem: I read that the Syncromesh support in the Indus ROM is buggy and doesn't work. There are some programs that fix this by uploading new code into the drive's RAM. Just search for "syncromesh" here in this board. Unfortunately, there's not enough space left in the OS ROM to include this drive update (my SIO patch replaces the international charset and currently there are only approx. 100 unused bytes). I already thought about this, too (plus a key-combination to clear the highspeed SIO table). It wouldn't be a big problem for the stock XL OS, but I'd have to analyze the various MyIDE OSes (they already patch the keyboard IRQ routine, but it's different for example in 3.1 and 4.3). So, maybe in the next version :-) so long, Hias

Yes and no: - For ultra speed SIO check a $3F command ("get speed byte") is sent to the drive. Atari800 doesn't know that command, but I guess this mode would work fine anyways, as the only difference to standard SIO mode is a different baudrate (which the emulator seems to ignore). - XF551 mode is checked with a "get status" command, but for XF551 mode bit 7 of the command is set (so it's $D3 instead of $53). - Happy 810 is determined via the special Happy "$48" command. Both $D3 and $48 commands aren't handled by Atari800, but the problem here is with the 1050 Turbo mode: 1050 Turbo mode is indicated by setting bit 7 of DAUX2, the command frame is transmitted in standard speed, the rest of the transmission is in high speed. The check for this mode is also done using the get status command, but here the command is unaltered. On a real Atari, only a 1050 Turbo looks at bit 7 of DAUX2 and switches to highspeed. All other drives stay at standard speed, send 5 bytes to the Atari which are received as garbage since the Atari is set to high speed. Since Atari800 ignores the speed setting, the SIO emulation sends the 5 bytes to the emulated Atari, which are here received nicely. So the highspeed SIO code thinks "OK, this is a 1050 Turbo". The real problems start now when the first sector is loaded. Since DAUX1/2 are used for the sector numbers, Atari800 receives requests for sectors 32769 and up, which are of course not present in most ATR images... so long, Hias

If you check that old thread where we discussed our wishlist, there are some glowing omissions in emulation which can be utilized to detect if you're on the real machine or not: Although one of these tricks could be utilized, it might fail in the next version of the emulator when the issue is fixed. IMHO it's better to just add a few lines of code and ask the user if he wants highspeed SIO support (like I did in MyPicoDos). Or build two separate versions, one with and one without the highspeed SIO code. so long, Hias

Yes, exactly. Most SIO2PC software (like the original SIO2PC for DOS, APE, AtariSIO) supports highspeed SIO at 57600bps. Newer peripheral devices, like the SIO2SD and SIO2USB, also support higher speeds than standard SIO. I did some tests with the SIO2SD and could get up to ~80kbps (speed byte 4). so long, Hias

Actually, I thought Austria would be able to loose all three games, but then Poland made a mistake :-) Yes, the patch automatically probes for highspeed SIO support (and the type of highspeed SIO - Ultra speed, XF551 etc. are all a little bit different) when accessing the drive for the first time. Then the result is saved in an (8-byte, for D1: to D8) table. If a drive doesn't support any highspeed mode, it's just used in standard speed. For "real" Ataris this would be great, but I won't recommend this if the game should also work fine with emulators. Most emulators only have very limited SIO emulation and for example if you run MyPicoDos with the highspeed code enabled in Atari800 it won't work (MyPicoDos then just shows "Disk Error"). Then, in general it's also better to enable the SIO patch of the emulator, because it's faster than the SIO emulation. so long, Hias

Hi! I just uploaded the first official release of my highspeed SIO patch to my homepage: http://www.horus.com/~hias/atari/ This patch adds highspeed SIO support to the stock Atari XL/XE OS and to the MyIDE OS. It's also the first patch that is 100% compatible with the MyIDE OS (tested with versions 3.x and 4.x). The package includes the full source code and also a precompiled EXE file so that you can create a patched ROM image directly on your PC (and then, for example, program it into an EPROM). so long, Hias

The original Antic docs might have contained some information (from the index: page 28: Cycle Counting), but unfortunately these pages are missing in the PDF... ftp://ftp.pigwa.net/stuff/collections/nir...0Info/ANTIC.PDF so long, Hias

I can confirm this, I had a similar problem on my main (PAL) 800XL a few weeks ago. The 800XL still worked fine, but sometimes the color saturation went down to almost B/W. Fiddling around with the power cord then fixed it again. Actually, the power jack was still OK (and contact cleaner didn't have any effect), but the solder joints on the PCB were going bad. So I took out the PCB, re-soldered the connections of the power jack and everything was fine again. so long, Hias

Real hardware. Why? This is a serious question,I don't get the point. I can play the old games and the old software. To use real Atari devices or to do some (more or less sophisticated) hardware hacking. A really nice example is the joystick port: program some pins to output mode and then use it to control other devices. For example I implemented an I2C stack for the Atari using 2 pins of the joystick port, the hardware is really simple: just the joystick connector plus 2 pull-up resistors. There are a lot of other existing devices, like the multijoy, MIDI-interfaces connecting to the SIO port, "real" Atari printers (like the 1020) etc. With a "real" Atari you can just connect these devices and use them. OTOH, I don't think that re-building a new Atari using old (out of production) chips is a good idea. IMHO the best solution would be to go the FPGA route and create VHDL (or Verilog) implementations of the original chip designs. Having these one could create an ASIC and go into cheap mass production (like the C64DTV). Or hardware hackers could easily extend the hardware, for example by adding another pokey instance and then upload the new code to an FPGA. The really nice thing about those programmable hardware devices is that hardware has actually become software now :-) Unfortunately (as someone already mentioned in this thread) creating all these VHDL models is neither easy nor cheap... so long, Hias

Yes, this looks OK. The second circuit diagram is the FSK decoder. To interface it with the line-out of a CD player you might need to adjust it a little bit, though. I was just digging through my docs and found the (photo-) copy of a recorder interface, i.e. the circuit to connect a standard tape deck to your Atari. Unfortunately the quality is quite bad (circuit diagram originally printed on a grey background or so) and scanning it didn't work too well :-( The original article is from the german magazine "HC Mein Home-Computer", October 1984, pages 38-41. BTW: I haven't tried to build this interface, I collected this article more or less just out of interest. This all depends on what you want to do. The drawback of most turbo tape interfaces is that you need some special loader software. If you copy the original tapes to an audio CD it's slow as hell, a waste of space, but you have no compatibility issues and a 100% archive of the original. Personally I wouldn't invest too much effort in re-building one of the turbo tapes or the MegaCD. These are very interesting devices from a historical point of view, but nowadays I'd recommend just using CAS files on your PC with one of the Atari peripheral emulators (eg APE, I also just added preliminary tape support to AtariSIO). Maybe we could also convince Jakub to add CAS support to his SIO2SD interface :-) BTW: while looking at my docs I also found an article about the MegaCD interface in one of the ABBUC magazines. Now I'm pretty sure that it was the MegaCD interface that I was thinking about. so long, Hias