TEDIT.ARC a text editor published in Analog Computing. Maximum file size 32kB. (see below) TEDIT2.XEX same as above, but patched so you can now get a directory listing from drives 5, 6, 7 and 9 too. VTEX13.ARC by Larry Richardson. A text viewer. Enables you to go through a (text) file page by page. No need to convert from Ctrl-M Ctrl-J to Atari EOL's first. Another feature let's you save part of a file. WHEREIS.ARC find out where a file is. Goes through all subdirectories it finds on a disk or partition. SUPERUNA.COM UnARC all your ARC-files. SUPERARC.COM ARC all your files. DISKCOMM.ARC Turn a complete floppy into one or more small files. VTOCFIX.COM Fix MyDOS (pre-4.55 versions) VTOC. BOBTERM.ARC My favorite software for using pre-ISDN and pre-DSL modems.
T:Edit is a great little text editor by Brian Schappel. I use it for all the text I write on the Atari. (Only time I use a PC for writing texts is when I'm either on the internet or when I'm editing some html stuff. But even the html stuff I often start on the Atari. html needs a lot of '>', '<' and '/'. On the Atari, you don't need to press shift at all. On American PC keyboards you have to press shift for both '>' and '<'. On a German keyboard, you have to press shift on '>' and '/'. '>' and '<' are on the same key). If you're gonna check out the source code, please look into two annoying bugs: deleting larger blocks of memory can sometimes lock up T:Edit. After deleting larger blocks of memory, or replacing a larger text with a smaller one, every world you type is wrapped to the next line (except the first one). And it would be very nice, if the directory routine would be able to show us the contents of drives 5, 6, 7 and 9 too.
It's been done, T:Edit has been patched. You can now see directory listing from D1: through D9:.
B64.ARC a Base64/MIME decoder written by Tom Hunt. YAU.ARC Yet Another UUencoder and Yet Another UUdecoder. DISKFORM.ARC Turns ATR and XFD files into something the Atari CAN read. This one runs on the Atari, not the PC. Thanks you Ken Siders! DISKCOMM.ARC Turns disks into files that can be easily transferred via internet/bulletin boards and back. Especially on disks that are far from full, DISKCOMM saves a lot of memory/disk space when compared to for instance the ATR format.
ZIP2BB.ARC The "how to connect a ZIPdrive to my BlackBox" story I sent to Atari Classics.
It never got published. PWRLEDXF.ARC How to add a power LED to your XF551. XL600K64.HTM How to internally upgrade your 600XL to 64kB.
And here's a way to get your 1050 to use 25% less power and generate a lot less heat.
XEP_1.HTM Erhard Puetz tells us why the XEP 80 seems to be so slow, that it isn't, and how he stumbled onto some programming errors a la Atari in the driver. XEP_2.HTM More about the XEP 80 and how he fixed the XEP 80 driver. Also by Erhard.
Both XEP_1 and XEP_2 used to be in XEP80.ARC, which contained some errors, omissions and random data. I cleaned them up and html-ized them, by hand. BobTerm XEP80 driver. Erhard's fixed version, which will now keep up with a speed of 9600 baud, instead of the 4800 baud that used to be the maximum. There is still some (bogus) data send to the unused joystick port and the 40 column screen isn't switched off. Meaning that if we could switch off the 40 column display (user choice), data could be sent to the XEP80 even faster. This version is fixed to 50 Hz. Maybe somebody could add a little routine that looks at $D014 (PAL) to determine which frequency should be used. BBSPUP.ARC or how to speed up the printer port on the Blackbox. STABILIZ.TXT by Bob Puff. Some Atari's just don't seem to want to talk to some parallel bus devices. Here's a fix. MODSTAB3.TXT by me. There seem to be some errors in Bob's text.
Forget about the above modifications. A real solution to the problems with Phi2 can be found here.
MOUSE.ARC John Maris tells us how to use an ST or Amiga mouse on the 8 bit Atari without its driver taking up all of our CPU time. MOUSEINT.ARC The driver in .M65 format plus a demo to show you how it works. STM18BIT.TXT A textfile describing how to make the right mousebutton work on an 8 bit Atari while ST compatibility is kept. Very easy upgrade. INDUSGT.ARC Loading the Synchromesh software can take a long time. But without it, all disk access is slow. Here's a way out.
The picture on the left is the schematic of how you can use the intensity bit/signal on your XEP80. The picture on the right is an external convertor that will take your XEP80's signal and create an HSYNC and VSYNC signal from it.
Click on the picture to enlarge.
The accompanying text has been written by Hans-Christof Tuchen. It's kinda like the deluxe version of what Bob Woolley did in his article in Atari Classics. You might also want to check out this article, also by Hans-Christof. And here is the text belonging to the schematic on the right (by Günther Bartl).
Here are the data sheets to the chip inside the XEP80. It can handle 64k by 16 bits RAM and color. They even mention bank switching memory in these sheets. To bad Atari never used the chip to it's full potential.
Read out the settings of your BlackBox using BB_SETS.ARC.
Or change the partition list using Erhard Puetz' BBPLD.ARC.
It contains BBPLD31.COM which works with SpartaDOS and BeweDOS only and BBPLD40.COM which should also work with MyDOS but doesn't. (BBPLD40.COM wasn't assembled yet when I got it. Lee assembled this one for me. Thanks Lee!)
But this solution is even better. Ever wondered what U35 on the 130XE schematics was supposed to be? Well, it's a 74LS95B. If the CO25953 is too expensive for your taste ($10 at Best Electronics and $12.50 at B&C Computervision) you can now replace it by using a GAL plus a 74LS95(B). You get pin compatibility and one of the unused pins - on the GAL - can now be used to switch the RAMdisk off completely.
Ever heard of the Commodore 64? It runs at just under 1 MHz. Now one of the software guru's of the C64/C128 scene thinks real time video is possible on her computer. Check out REALTIME.ARC and tell me this can not be done on our trusty 8 bit Atari.
It obviously can on the C64, check out Nicolas Coplin's site.
Josef Soucek's site even has source code to real time streaming data stuff. Plus lot's of other nice stuff.
Mr-Atari has written a viewer for his MyIDE interface. Check out his site.
His viewer and docs.
An MPEG file you can watch on your Mac or PC that shows how the movie looks on his monitor.
I've looked at the viewer. I'm not an assembler programmer, but I guess converting it to BlackBox or even ASPI compatibility shouldn't be to big a problem for somebody who's done some "drive access" assembler code before. If you decide to make it ASPI compatible, I'll help you as much as I can. Remember, I wrote two CD Tools that are both fully ASPI compatible.
And guess what? There once was a Quickscan (webcam)..... with a parallel port. One of the guru's in the C64 scene made a small interface for it and got it to work on her computer. Unfortunately, the information about this interface and the rest of the information on that site has disappeared off the internet. It looks like the software might be available here. But only on .D64 format. I guess that's like our .ATR format.
Would be nice if we could have something like that on our 8 bit Atari's. Our HIP and RIP formats should be just as nice as those C64 modes.
Here's a picture of the webcam I bought a while ago (warranty is probably over, but it was one of those things I HAD to buy.) My USB cartridge has arrived. Now all we need is somebody who will write us some software.
And here is an Atari Writer printer driver for the Hewlett Packard Laserjet printer. I haven't tried it since my Canon's ink has dried up. Silly thing keeps swallowing some lines whenever I use it to print something using my Atari 8 bit. (That's why I don't use it very much and why the ink get's a chance to dry up.) I've heard from people from the C64/C128 scene that they have software that solves this.
You'ld like to boot two systems from one daisy chain? Or maybe you/your kids/cousins all wanna play the same game at the same time? Without having to swap floppies between systems? Or you wanna edit a file on one computer and run it on another? Or test the same software on two different computers? Why not order the Automatic 2-Computer Interface by the Frankfurter hardware guys.
It will let you connect TWO Atari 8 bit systems to ONE daisy chain, making it possible to share all your SIO devices between two computers. (you could order more than one to connect more computers, but you'ld need x-1 automatic 2 computer interfaces for x Atari 8 bit computers.) The description is on another site and you have to click on the right link on their page. Which is available in both german and english. BTW you can't access the daisy chain on both computers at the same time. The Automatic 2-Computer Interface waits a certain amount of time before 'the other computer' is allowed access to the SIO devices. [I personally own one of these. They are great. If I wanna test some software on my 1MB XEGS, which doesn't have a PBI, I use my main system to copy the software that is to be tested to my XF551. After that I can access the same disk in the same XF551 from my XEGS.]
The A2RI was developed by Thomas Grasel of the ABBUC Regionalgruppe Frankfurt. He has allowed me to share the instructions on how to build it with you. Text is in German but includes the layout for the PCB.
And here is HARdwareDoc's MIDI Interface. It's 100% MIDI Mate compatible, lacks the sync ports, but has MIDI IN, OUT and THRU ports. The page is in German.
You can use the interface with either the SIO-cable or the SIO-connector or both.
You want a harddisk, but you computer doesn't have a parallel bus interface (like the 1200XL or XEGS)? Or you want a harddisk interface that's easily moved from one computer to the next?
Why not try the SIO2IDE interface? The site is in Polish, but the zip file contains English text. You'll find a list of all the different versions on the left side.
All versions of the SIO2IDE interface come with a SIO port and an IDE connector. And all versions have to be set up before they can be used. For this, you have to copy some files to the hard drive you are intending to use with the SIO2IDE interface. The interface needs these files for it's own housekeeping. And here is where the main difference lies between versions 3.x and below and versions 4.0 and above.
With versions below 4.0, you have to connect the hard drive to the internal IDE interface of the PC. You have to open your PC for this. To overcome this, versions 4.0 and above also have a USB connector. With it, the hard drive turns into an external hard drive you can connect to a PC. This USB connector however can not be used to connect USB devices to the Atari 8 bit computer.
Marek seems to have his upgrade build into his computer (see the pictures on his site). But if you do the upgrade externally, you will be able to move the upgrade from one Atari 8 bit computer to another. I myself plan to use it with above mentioned Automatic 2-Computer Interface. That way, it is possible to share it between two computers without unplugging anything. Since you can use a jumper to switch D1: and D2:/D9:, one could have one MyDOS and one SpartaDOS/BeWeDOS boot partition. SIO2IDE works with ATR files. One ATR file is one partition. You can have up to five active ATR's on versions 3.x and up to eight active ATR's on versions 4.x. A configuration file (which the Atari doesn't see) tells the interface which of the many ATR files can be seen by the Atari and to which drive numbers they have to respond. As far as I know, you can have as many (ATR) files on your harddisk as you would have on a PC harddrive. You can find a jukebox utility that will help you select which ATR's you want to use on Trub's site. All versions of SIO2IDE will handle normal speed (19k2 baud) as well as high speed (51k2 baud).
Version 4.3 of the SIO2IDE interface firmware can handle two devices. Pre-4.3 versions can only handle one master or one slave. IDE uses the master and slave drive principle instead of the system SCSI uses, where each device has an ID (0-7) and - if needed - a local unit number (also 0-7).
The USB chip doesn't seem to be installed on this printed circuit board, but the chip used is an SMD type. These are soldered directly onto the traces. So it's on the other side.
Both picture were taken from the SIO2IDE site and trimmed a bit.
The SIO2SD uses an SD-card, as known from car-navigationsystems and mobile phones, as a storage device for your Atari 8 bit computer. The device can emulate D1: through D8:, connects to your SIO bus and currently it's default high speed index is 6 (69000 bps). Settings from 1 to 16 are supported, but the higher speed settings (lower high speed index) at some point will result in errors.
If your SIO2SD doesn't already have a 14.31318 MHz crystal, you will need to replace the crystal and update the firmware. Otherwise you're stuff with "D1:-D4:" and a maximum speed of 51000 bps.
HardwareDoc has translated the Firmware from English to German. As the German version isn't available on the SIO2SD site, you'll have to contact HardwareDoc. He can be found on the ABBUC Site.
The data is stored in ATR or XFD images from 90 KB up to 16 MB.
You can find more information about this device, including a schematic and Atmel software, on this page. The text is in English, but a Polish version of the site is also available via a link on that page.
HARdwareDoc developed a small device, that enables us to connect a Wii Nun-Chuk to the joystick port of an Atari (or any other device with a similar joystick port). You will find his Nun-Joy page here.
Since a couple of years, a new trend has developed in the European Atari fair/meeting scene. People have started to play games in game competitions. Mainly because of two old ideas that have been picked up by two guys from Eastern Europe.
The first one is the MultiJoy interface by Radek Sterba (Raster). Radek's version enables one to connect up to 8 joysticks to 1 computer.
The picture was borrowed from Fandal's site. In it you see a modern version of the MultiJoy8. Other versions might look different on the outside, but on the inside they are basically the same.
It is possible to build and support a version that will handle 16 joysticks. But the device does get a bit big. The good news however is, that HARdwareDoc is working on an improved version of the MultiJoy interface called UltraJoyPro. The UltraJoyPro will be able to handle joysticks with autofire and HARdwareDoc's Nun-Joy interface. But the best feature in my opinion is, that the UltraJoyPro will be cascadable. Meaning you plug the first UltraJoyPro into the computer and the second UltraJoyPro into the first one to increase the amount of joysticks you can use. Although 16 still is the maximum number of joysticks you can use at the same time. Why do I think this is the best feature? It was my idea! :-)
Your computer only needs to have two joystick ports for either version of this interface.
The second one is the MultiLink interface by Jiri Bernasek. It enables you to connect up to 8 Atari 8 bit computers together. Jiri took a good look at the GAMELINK II interface and improved the hardware.
The Regionalgruppe ABBUC Frankfurt (RAF) once sold this version of the MultiLink Interface.
Jiri also wrote some games for the interface and has now put together a toolkit (which consists of NTWGAME.ARC, MWORMS.ARC and MWSOURCE.ARC. You can find these files by scrolling down to where all the MultiLink games are).
JOY4.ARC the predecessor to the MultiJoy interface. Contains all you need to build the hardware plus a test utility that will also run on the MultiJoy interface.
QUADRO TRON is a version of TRON:
This version will run on the hardware described above.
MULTIJOY.DOC a text file (probably by Andreas Magenheimer).
MJOY.ARC three files by Radek Sterba. If somebody could please translated them from Czech to English...
MJOY_GIF.ARC a GIF to big for the Atari 8 bit, that shows the schematic for the MultiJoy
interface.
CERVI.ARC a snake clone for the MultiJoy interface.
If you don't speak Czech, try this file.
CERVI2.ARC is a version of Cervi for those who can find a MultiJoy16 Interface and more then 8 but no more then 16 friends who want to play Cervi.
MULTRIS.ARC Multi Tetris is a Tetris clone for the MultiJoy interface. Use max. 4 joysticks for max. 4 players each filling up their on column.
F2BETA.ARC Here's the beta version of Bremspunkt. Bremspunkt is a four player racing game by Mad Butscher/F2. For the fully functional version you have to go to Foundation Two's homepage and click on 'Releases'.
The following games have been written by Florian Dingler. Icehockey hasn't been finished yet.
Icehockey: An ice hockey game for up to 6 players.
Card Grabber: A card is pulled from the stack. If it's yours, grab it. React fast. Simple idea, highly addictive.
Sheep Race: Eight sheep running like crazy. It is your task to make sure they run in the right direction.
You can find ATR versions of Card Grabber and Sheeprace at Florian's site.
Shot 'em all by Radek Sterba. For up to 16 players.
On a 400/800 (if you can find a PAL version), two players are the minimum, three is a possibility, but four players can play against each other.
On an XL/XE without MultiJoy interface, two players are needed.
On an XL/XE with the MultiJoy interface, two players are needed, but a third and even a fourth player can join in.
Fujiama Run by Schmutzpuppe. Partly coded during Fujiama 2006 in Lengenfeld, Vogtland, Germany. Fujiama Run is a running game that can be played by up to seven people. Be sure your joystick can take a beating, if you save your joystick you will never win!
Mashed Turtles by Fandal and PseudoGraphics. For 2 to 8 players. The goal is to get as many turtles across the road as possible.
Fandal has converted a lot of existing games to multijoy games. You can find those (and the games above) on his site.
CERVI and MULTRIS will not run on the interface described in JOY4. Bremspunkt, Icehockey, Cardgrabber, Sheeprace and Shot 'em all will only be partially usable with that interface. QUADRO TRON and the test utility in JOY4 will run on the MultiJoy interface, but will use different joystick ports on the interface. To fully enjoy Cervi2 you need the MultiJoy16 interface.
GAMLINK2.ARC The way it all started. Unfortunately without schematics.
AGDAGON.ARC The game Maze of Agdagon and it's descripton.
HARDW2.ARC Two 62 sector GR.8 pictures. Both of the new design by Jiri Bernasek. One
black on white, the other white on black.
MULTIDSH.ARC contains the game Multidash (simular to Boulderdash), the schematics to and a doc file on the MultiLink hardware.
MULTIRAC.COM MultiRACE is a game like Pole Position, but with two players per screen, on icy roads and in grey.
If one person is playing, the rest of the screen is black. If there are two people playing on one computer, the lower half looks simular as the top half.
NTWGAME.ARC Three text files by Jiri Bernasek explaining how to code games for the MultiLink interface.
MWORMS.ARC MultiWorms, a snake clone. Written by Jiri for explanatory purposes.
MWSOURCE.ARC The sources to both parts of the game MultiWorms; the game routine and the networking routine.
One player
Menu
Two players
Score board
Speed Up! by PseudoGrapx and Raster. Looks like a racing game. I haven't tested it on a real Atari 8 bit computer yet.
They are fun to play at fairs/meetings/conventions.
People used to sit together and play, until television and computers came along. Multiplayer games are a way to get people to sit together and play again.
They can be used to lure people into becoming Atari 8 bit fans.
When my cousins were younger and we had a birthday at my house, I'ld entertain them by letting them play games on my 8 bit Atari. I guess one of my uncles even bought an Atari (ST) instead of a PC because his kids loved playing games on my computer. The MultiJoy or MultiLink games would have been a hit.
A jump and run game. Everybody starts in the same 'room', but each can go it's own way. As you pass another player/other players, each sees the other
player(s) move over his or her screen.
Same as above, but now in 'Tomb Raider' perspective.
Some sort of flight simulator where you can do air to air combat.
A game where you have to work together to get somewhere. The goal could be to rescue people from a fire or the water.
A multi user dungeon. But not via modems, but via MultiLink.
RISK
Gunfight at the OK Corral. Use a joystick to look around and maybe a light gun to shoot the opponent. If the enemy sees you, you computer replaces your 6th sense. A press on the SPACEBAR turns you in the right direction.
A multi computer/multi screen demo. You can have lot's of sound channels (although you need some to sync. the computers). Or have shapes leave one screen and appear on another.
Labyrinth/Factory/Old sewerage system: all players start on their end of a maze/factory/sewerage system. They can only reach each other by playing the game to the end. Sometimes they can do something to help others (like picking up a key that will open up a door to a shortcut that helps somebody else), sometimes they can do something that's not as nice (like throwing a banana peal down a shute, it lands in the path of somebody else and (s)he breaks a leg and has to use crutches).
TRON. But not seen from above, but as if you'd be on motorcycle speeding toward a wall yourself.
Pole Position for MultiLink. But you don't see the back of the car you are driving, but the instrument panel/dashboard.
One game, three screens (and three computers). One screen shows what happens in front of you. The other two show you the view to your right and left.
Football (either soccer or American) as seen through the eyes of the football player.
Paintball. You eliminate members of the other team by finding them and shooting them with a paint gun. Light gun support would be great here.
PacMan VS.. (Idea by Phil)
With just one computer, each player is a ghost. Points rack up by catching PacMan or eating the fruit. In the better-graphics-systems that have this game, each ghost can only see a small area around them. When they eat the fruit, they can temporarily see more of the board/screen. When there are only one or two players, the remaining ghosts are gray computer ghosts that do nothing until they are touched by a player ghost at which point they become the same color and are on that ghost's "team". Ghosts can enter the ghost house, which is useful for when PacMan eats a power pellet.
With two computers, one player is PacMan on one screen and can see the entire board. The rest of the players are the ghosts on the other screen, again with the limitation of only being able to see a small area around them. PacMan has a short trail. He gets points by eating the dots, power pellets, and fruit. When one of the ghosts catches PacMan, that player trades and gets to be PacMan.
The game ends when one player reaches a selectable amount of points. For example, 3,000 for a short game, 8,000 for a longer game, 15,000 for even longer.
If you have an idea that isn't on my list, please tell me about it.
One of the computers (the master) needs to generate a sync pulse. At the moment this is done by tying two POKEY sound channels together. This way we lose two sound channels on the master computer. If the drivers for the sync signal and the communication could be in (a) separate file(s), it would be possible to use different ways to generate a sync signal and to use different interfaces:
If we'ld use the proceed line on the SIO connector (it's never used as far as I know), some hardware on the MultiLink Interface (that would have to be redesigned) could generate the sync pulse. The (MultiLink compatible) software in each computer that is booted, would check for the existence of a sync pulse. If none is found, the computer would know it is the master computer and switches the state of the proceed line to low (I'm assuming it's normally high). As a result the attached MultiLink Interface would generate the sync pulse. All other computers (the slaves) after that, boot from the master and also check if a sync pulse is already present. Since they boot off the master computer (who's MultiLink Interface generates a sync pulse), a sync pulse already exists and the slaves will not generate a sync pulse. The sync pulse could also be used on a deluxe version of this new MultiLink interface, to switch all communications on the slave computers from the "normal" SIO bus, to "MultiLink only" (read: no need to unplug any drives). Since we want the user to have a say in this, a manual switch would have to be on each deluxe MultiLink Interface. This deluxe version could also, upon receiving a signal from the Proceed line, cut off all communications to the "normal" SIO bus on the master.
If we could use external drivers, we could use different interfaces. Like the USB cart and via it maybe even BlueTooth or WLAN.
Electron has announced, that his work on new Atari invention: Video Board XE is to be finished soon. The idea is based on the GTIA replacement with a new chip. As a result we've got:
GTIA compatibility - only old PMG and so called GTIA modes don't work.
Sprite blitter with it's own 512 KB of RAM. It generates sprites with sizes from 1x1 to 256x256 points in the resolution of 320x192, each sprite in 256 colors. Number of sprites is limited only with blitter effectiveness, at least it wil be 30 pieces with 32x32 size and 256 colors per frame.
Programmable priorities for sprites and background. Simple sprite collision detection.
Programmable x and y sprite positions with 1 hi-res pixel precision.
Two programmable 256 color palettes - one for the play field and one for sprites. The palette colors are chosen from the 65536 colors (Hi-Color RGB).
Play field colors map in 8x8 and 4x4 pixels resolution, for each such block a 1 of 32 color-sets may be chosen (all play field colors are changed), it is also possible to scroll color map vertically/horizontally with 1 pixel precision.
Ability to mix hi-res and color modes with appropriate definitions in the map of colors..
RGB output for monitor/TV.
Commend by the webmaster: The original GTIA is neither replaced nor disconnected. Existing software will be able to use the existing GTIA chip.
On the first picture below, you can see the Video Board XE installed on a 130XE motherboard with only 64kB installed. Motherboards like the one in the picture were put in cases with cheaper plastic than was used in the earlier years of production of the XE series and sold in Europe as 65XE or 800XE. The resistors you can see at the location where the CO25953 ought to be, are zero Ohm resistors.
Here, take a closer look!
And just to wet your appetite, here are two screen shots.
The VBXE's memory is accessed via $D1xx, $D5xx, $D6xx or $D7xx. Your choice!
Here is a very early and incomplete version of the Video Board XE specifications. Unfortunately, 99% of the text is in Polish. Can somebody please translate the text into English?
Here's a demo of what the Video Board XE is capable of. You might have to restart the movie player to get good picture quality.
And here's another one.
And already somebody is working on a game for it.
Tomasz Piórek a.k.a. electron, the developer of the Video Board XE, now has an internet site dedicated to the VBXE. The site looks very promising, but unfortunately, it's in Polish only.
Tomasz Piórek has just published the following information. I haven't really looked at it yet (just converted it from .7z to .zip), but I'm under the impression that it contains all the stuff you need to build your own VideoBoard XE.
You want a harddisk, but you computer doesn't have a parallel bus interface (like the 1200XL or XEGS)? Or you want a harddisk interface that's easily moved from one computer to the next?
The USB chip doesn't seem to be installed on this printed circuit board, but the chip used is an SMD type. These are soldered directly onto the traces. So it's on the other side.
The SIO2SD uses an SD-card, as known from car-navigationsystems and mobile phones, as a storage device for your Atari 8 bit computer. The device can emulate D1: through D8:, connects to your SIO bus and currently it's default high speed index is 6 (69000 bps). Settings from 1 to 16 are supported, but the higher speed settings (lower high speed index) at some point will result in errors.
