rdemming
-
Content Count
1,254 -
Joined
-
Last visited
Posts posted by rdemming
-
-
I don't have a developers jag, but from what I understand I only need to put a stubulator rom in the jag and solder on the little pin header so I can get a little ribbon cable to go from the Jag to the Alpine board. Any other changes?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.
Are there any sites with info on the Alpine interface cable? Would be nice to know if the ribbon cable is a straight through or not.
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)
Do you need the cable if your not debugging? Say you just want to download something to run only. Can you do that? Also can you download and run something on the alpine without the stubulator rom in an unmodified jag?
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
-
Got me thinking...does this 'message' actually do anything? If Nu is RTS, the capitalised U in the middle implied to me that the hex value mattered...
So for you ST people, what does
44 61 76 65 20 53 74 61 55 67 61 73 20 6C 6F 76 65 73 20 42 65 61 20 48 61 62 6C 69 67
translate to?
Probably not much. Note the branches to odd addresses. That can't be good.
Robert
-
Last V8 sucked on the A8 also. I dont know anyone that finished that on the A8 (you almost have to cheat to win). The C64 was more balanced.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
-
AFAIK an Atari XL/XE trackball need no modification. It's exactly the same thing as an original ST mouse. (not sure if the trackball supports 2 independant firebuttons)
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
-
ang on.. couldn't the old atari track ball be modified to work on the Jag?if so that may be quite nice
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
-
Are unencrypted games compatible with my Memory Track cartridge?No games currently support saving in any form, however even if they did, the Memory Track cartridge is not a Bypass cartridge, so unless you have a modified Jaguar or JagCD, the game would not load.
American Hero does support the memory track. Or doesn't that qualify as an unencrypted game?
Robert
-
But the fact that the name may be confusing to some and with many different versions of this idea now available, you'll notice that when I discuss the topic I refer to the whole concept as a "CD-Bypass", to avoid confusion.
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
-
Oh yes, add "10th Frame" and "World Class Leaderboard" to this list too.How close were these to being ported? Damm you Access!
Leaderboard golf exists for the Atari 8 bit
Robert
-
Yes, I know that. But to call that word-chunks "Bitplanes" is a kind beside ... I think.
Is "Bitplanes" the right definition from ATARI itself?
Yes, "Das Atari Profibuch", the must have reference book about the Atari ST hardware, calls it bitplanes.
Robert
-
What you are talking about here?Interleaved Bitplanes ? Seems to be a paradox.
Bitplane means one Bit-Plane for the Full screen.
Colors depending on words can never be Bitplanes and you have a standard Bitmap depending on colordepth.
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 Amiga it was used for a purpose, to allow adjustable color depth. On the ST, it's just there to simplify Shifter.
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.
Most programs used software sprites that only modified small parts of the screen. Redrawing a whole new screen wouldn't be efficient for most things.
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.
It makes some esoteric effects faster, but it makes the important things slower. Transparency effects didn't have much application on a machine with 16 available colors, unless all you run are demos.
What about games. Even Shadow of the Beast on the Amiga uses this 'side-effect' of bitplanes to implement parallax scrolling.
The clever workarounds I spoke of were things like having 16 preshifted copies of each sprite to make dealing with bitplanes easier. Palette flash was seen because Atari's own routines copied one bitplane at a time, making it possible to see an image where some planes contained old data, giving the wrong colors.
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.
Again, I meant more by workarounds than just timing your redraws. Chunky pixels (where the pixel bits are arranged together) would have made ST graphics faster.
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.
Notice that Bill Gates doesn't complain about the "enlarge your manhood" spam.
Robert
-
BIGGEST ST hardware mistake: Shifter's dumbass memory arrangement wasted most of the 68000's power when it came to manipulating the screen. To change 1 low-rez pixel required 4 reads, 4 modifys, and 4 writes!!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.
This is why it was common to see 'palette flash' during screen updates, because sometimes you would catch a glimpse of a modification in progress. People came up with clever work-arounds, but what a freakin' mess!!
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
-
Was the JagFest in Rochester? If so, I missed it! (I am in the minneapolis area)
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
-
-
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
-
2 + 2 = 5 (for extremely large values of 2)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
) -
Most? I'd hope all kinds of shit disintegrate over time,Yes, most. Some "ingredients" of shit disintegrate harder than other like fibers and seeds. They even found fossilised dinosaur shit. Imagine that you can step into a millions years old turd
Robert
-
And I see the header connector and small wire jumpers installed for the MIDI board add-on. And if the crystals are 32MHz, then the boards will support the MIDI interface.Hi Glenn,
Thus the little wires at U6 and U2 are for the midi interface? I already wondered why they were for.
In your description about adding the remote reset wires, I saw that your Alpine also has a resistor and capacitor at the back side of the board (with one leg at the crystal). Does that have any purpose since my Alpine doesn't have that.
My Alpine has only an extra 2k2 resistor at the backside between pin 8 & 11 of U34 (GAL16V8). What the purpose of that?
B.T.W. Do you know the purpose of all the jumpers? I know there are a couple for the memory configuration and one for the batery power but what is the purpose of the rest?
Regards,
Robert
-
Yes. Ape shit, just like most other shit, disintegrates over time
RObert
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Alpine problems
in Atari Jaguar
Posted
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