rdemming

The Stubulator '94 is indeed needed with a CD-rom drive. The 93 version doesn't recognize the CD-ROM bios wether it is the normal or the developer bios. The 94 version works with the CD developer bios or the retail cd bios. With the stubulator 94 you can hold B while turning on the system to start a (unencrypted) cart directly. Hold C while booting to start the CD-bios. BattleSphere does indeed behave strange with the stubulator bios. Holding B does directly start JugsDD and boots an unencrypted CD instead of starting BSG. Maybe this behaviour is by design because in this way it is faster to boot unencrypted CDs than on a retail Jaguar. The Stubulator '94 / BSG combination starts the JugsDD directly while a retail bios / BSG combination first starts the regular cd-bios which in his turn starts BSG/JugsDD. Robert

If you view the boot track with ISO buster (sector view), at what offset does the ATRI header start. If it starts to early in the sector or maybe in the previous sector the CD-Bios won't find the boottrack. This happens when I copy a Jaguar CD with CloneCD 4.2.x and my Plextor writer. It writes the track earlier to the cd than then original. A normally written track with CD-record starts at offset $112 on my system. Try to create a copy of the CD by extracting all tracks with ISO buster, byte swap them and removing the zero bytes before the ATRI header and writing the tracks back to CD with CD-Record. Does this work? Robert

On Windows 98/ME you need to install Adaptec ASPI driver 4.60 (no later version). If you are using Windows XP, maybe you CD writer is not reporting itself with "CD-ROM" in the description line. Try to go to the options screen and enable the "Show all devices" option. Now the burn dialog shows all detected devices (even harddisks under XP). If it still doesn't show up, the CD writer may not be supported by CD-Record, the burner software used. To be sure open a command prompt and go to the installation directory. Then run: cdrecord -scanbus This shows the list of detected devices. If your CD-writer is found, please tell me the description shown by cd-record so I can add it to the detection routine. Robert

I think the Alpine cannot be used from BJL because BJL probably doesn't initialise the memory width registers for the cartridge. It seems that BJL is running from rom so the rom memory width needs to be set to 8 bits. Accessing Alpine memory must be done when the memory register is set to 32 bits. So as long BJL is running from rom, it can't access the cartridge in 32 bits. The solution would be loading a BJL loader into ram and setting the rom memory width to 32 bit. Then load the rom image to Alpine ram. Robert

A Stubulator '94 ROM is indeed required. The ribbon cable from Jag to Alpine is only needed if you want to use the Alpine's stop button. No other changes required. It is just a straight cable. You can easily make your own ribbon cable. Pin number one is clearly marked on the Jaguars PCB. Pin 1 on the jaguar should go to the upper right pin on the connector of the Alpine (seen from the back of the Alpine) Which cable do you mean? The ribbon cable from Jag to Alpine is not needed for loading or debuging. Only to return to the debugger with the stop button when the program is running. The cable from Alpine to PC is needed to upload programs and to debug them. You need a Stubulated Jag to upload from PC to Jaguar. It is also possible to load data into the Alpine from CD-rom. But since it is currently impossible to create encrypted Jaguar CDs, you need a hacked or developer bios in your CD-drive (you can't use a cd-bypass cart since the cart slot is already occupied by the Alpine). With the hacked CD-bios it should be possible to load from CD to Alpine with a normal Jaguar. The developer cd-bios needs a stubulator Jaguar and that surely works . Robert

Probably not much. Note the branches to odd addresses. That can't be good. Robert

OK lets cheat: Load "The Last V8" in Atari800Win Plus 3.1 and select "Monitor" from the "Misc" menu. Now type: C 134f ea ea ea and: cont This makes the game a lot easier B.T.W. You can use this code also on a real Atari if you have a Turbo Freezer add-on. Robert

Hier nog één. Robert

Not entirely true. My trak-ball certainly wasn't compatible with the ST but it seems that there already modified trak-balls out there. For more information see http://www.atariage.com/forums/viewtopic.p...2344&highlight= Robert

Most likely yes. The Atari trackball could be modified to behave like a Atari ST mouse or Amiga mouse. Since there is already code for reading ST mice it should be no problem to use the trackball then. But probably modification is not necessary (just an adapter from DB-9 to VGA style connector). Just interpret the signals on the joystick input correctly. Robert

American Hero does support the memory track. Or doesn't that qualify as an unencrypted game? Robert

CD-Bypass seems technically a wrong term to me too since it is not bypassing the CD. I still need to throw a CD in the "toilet" to load since it is still not loading from thin air. Maybe the term "CD encryption verification bypass" is technically better since it bypasses the encryption verification process of a CD. Robert

Years ago I also tried to use HD disks as DD disk but it turned out that is was quite unreliable. If I remember it correctly this is because the magnetic material of HD disk is "harder" than DD disks. The little magnets on the disk are harder to flip. HD drives thus uses a stronger magnetic field to set the bits. With the weaker magnetic field of DD drives the bits are not completely set/reset and can fall back to their previous state. Robert

Hi Steven, The cartridge seems a great product to me. Just a few questions: Is the bankswitch method used compatible with the XE cartridges? In other words, can I flash an image of for example "Desert Falcon" into the cartridge without modification? Currently you sell the cart with a 1 Mbyte flash chip. Can I replace it with a 8 Mbyte flash chip myself at a later time or does the 8Mbyte version use a different PCB. Regards, Robert

Leaderboard golf exists for the Atari 8 bit Robert

Yes, "Das Atari Profibuch", the must have reference book about the Atari ST hardware, calls it bitplanes. Robert

OK I try to explain: Atari ST screen memory (low res, 4 bitplanes) word 0: 16 pixels of bitplane 0 word 1: 16 pixels of bitplane 1 word 2: 16 pixels of bitplane 2 word 3: 16 pixels of bitplane 3 word 4: next 16 pixels of bitplane 0 word 5: next 16 pixels of bitplane 1 word 6: next 16 pixels of bitplane 2 word 7: next 16 pixels of bitplane 3 etc... Amiga screen memory (4 bitplane mode) (as far as I remember) word 0: 16 pixels of bitplane 0 word 1: next 16 pixels of bitplane 0 word 2: next 16 pixels of bitplane 0 etc... word n+0: 16 pixels of bitplane 1 word n+1: next 16 pixels of bitplane 1 word n+2: next 16 pixels of bitplane 1 etc... word n+0: 16 pixels of bitplane 2 word n+1: next 16 pixels of bitplane 2 word n+2: next 16 pixels of bitplane 2 etc... word n+0: 16 pixels of bitplane 3 word n+1: next 16 pixels of bitplane 3 word n+2: next 16 pixels of bitplane 3 etc... On an Amiga each bitplane had its own memory address while on an Atari ST there is only one memory address. Robert

POV can be found on the Umich Atari Archive. No idea if it is the latest version though. http://www.umich.edu/~archive/atari/Graphi...s/Raytrace/Pov/ Robert

On the ST you could have 1, 2 or 4 bitplanes. Although not as flexible as the Amiga bitplanes, isn't that the same as adjustable color depth? And using bitplanes makes also the Amiga graphics processor simpler. I still don't see the difference. Luckily that software sprites are drawn then in 16 pixel chucks instead per pixel. The same problem applies for Amiga software sprites or blitter objects (blobs). Only the Amiga had hardware sprites to do it for you. What about games. Even Shadow of the Beast on the Amiga uses this 'side-effect' of bitplanes to implement parallax scrolling. Yes, I agree that drawing sprites on a bitplaned screen is harder/slower than a complete pixel in a byte screenmode but the same applies to Amiga software sprites. And the flashing is still bad programming. On a non-bitplaned display you can have similar graphics glitches like bottom part of sprite running behind the upper part of a sprite. Yeah, making 8 pixel wide pixels or better 16 pixels wide pixels would indeed make things fasters. Nice for big scrollers but not much anything else. My point is that most of the disadvantages of bitplanes you describe for the ST are valid for the Amiga aswell. This because the Amiga uses bitplanes too albeit laid out differently in memory. But the Amiga has some extra hardware features that solves some of those disadvantages (hardware sprites, fine scrolling). Great for sprite based and scrolling games. But in for example a 3D game, the Amiga would suffer the same disadvantages of bitplanes as a ST. Robert

What is this different than an Amiga? As far as I know the Amigi also has bitplanes but they differ from the ST ones that the 5 Amiga bitplanes had each their own memory address and the 4 bitplanes of a ST are interleaved word by word. So the same disadvantage exists on the Amgia aswell. Besides, most programs (except for scrolling) don't read the current screen data but just clear the screen and draw it again. Bitplanes make it indeed harder to manipulate the screen on per pixel basis compared to modes where a complete pixel is in a single byte/nibble. But it makes parallax scrolling and transparancy effects much easier and quicker. Why is double buffering (Draw the next frame in an offscreen buffer while the current frame is displayed. Then in the vertical blank interupt set the screen memory pointer to the frame that was drawn offscreen.) a "clever work-around"? It is a well known technique to prevent screen drawing flickering and is used on 8-bit Atari's, Atari ST, PC and I would bet also on Amigas. Every program that shows this kind of flickering is just badly programmed and has nothing to do with bitplanes. Non bitplane graphics mode suffer from the same flickering problem if you manipulate the visible screen (without double buffering). Robert

JagFest was held in Rochester (United Kingdom) on June 14/15 2003 Robert

You could try to read the manual of the DOS version of APE since many of the concepts are the same for both the DOS and Windows version. Robert

At 16-32 systems they sell them new for 9 pounds. Robert

The problem with the Atari blitter is that it can't run in parallel with the main processor. Thus when the blitter is busy, the 680x0 is waiting. (BTW the Amiga blitter could run in parallel with the 68000). Next the blitter is 16 bit while the 68030 in the TT is 32 bit. This and the 32Mhz clockspeed of the TT 68030 makes the 68030 software blitter emulation faster than a hardware blitter. On the other hand, the 16 Mhz 68030 in the Falcon is a 68030ec version. This is a 68030 with a 16 bit databus effectively cripling the 32 bitness of the 68030. This made it worthwhile to have a 16Mhz blitter in the Falcon. Regards, Robert

Hey, you are right even for 'normal' values of two Let's do the math: Equation 1: (2+2)*0=0 Follows: 2+2=0/0 Equation 2: 5*0=0 Follows: 5=0/0 Substitute 0/0 in equation 1 with equation 2: 2+2=5 Robert (Mathemagician )