Amiga questions you've always been too embarrassed to ask

[diablothe2nd]

Originally Posted by demolition

Most will do 82 tracks

does that mean more than 880k of space was available, but just not used for compatibility?

Originally Posted by demolition

Amiga DOS disks always use 4489 sync, but other syncs are sometimes used, mainly for copy protection usage. If a copy program tries to read a protected disk using the wrong sync it will probably not be able to read the track.

how would the amiga be able to read a disk done in this way for copy protection reasons?

so, if you were struggling to copy an original game disk for example, would you choose to look all the way to 81, then tweak the sync number until you get all green zeros?

[demolition]

Originally Posted by diablothe2nd

does that mean more than 880k of space was available, but just not used for compatibility?

I guess so. 2 extra tracks would provide 22kB of extra space. It is probably not all drives which are capable of reading all 82 tracks, so it makes sense to keep it on a safe level.

Originally Posted by diablothe2nd

how would the amiga be able to read a disk done in this way for copy protection reasons?

so, if you were struggling to copy an original game disk for example, would you choose to look all the way to 81, then tweak the sync number until you get all green zeros?

I don't know exactly how it work in xcopy, but not all tracks need to use the same sync word. Normally one would disassemble the loader (the boot block obviously has to use the standard sync) and you would be able to see if it changes the the sync word when reading certain tracks. Thus you would have to dump each track separately using their individual sync words.

[diablothe2nd]

i see! thanks for the info

[demolition]

I think Nibblecopy in XCopy will try other syncs if it is unable to read a track. It can take a long time, but it is able to copy some copy-protected disks.

[xArtx]

Lol, I know where to get a Kickstart...

drives are emulated and disk images are in ADF form unless you're running from a real amiga which can do both ADF and the real thing

That's the answer to one question, the other is where does the emulator get the Kickstart from?

Originally Posted by diablothe2nd

We cannot tell you where to get a kickstart from other than by pulling it directly from your real amiga or from Amiga Forever. The kickstarts are still copyrighted so supplying you with them would likely get EAB shut down. Google is your friend though

drives are emulated and disk images are in ADF form unless you're running from a real amiga which can do both ADF and the real thing

emulating Amiga ON Amiga is only needed when you're running AmigaOS 4.x MorphOS AROS etc from a non native amiga system like the SAM systems, G4's or X86 systems. you don't need to emulate the amiga when using the real thing. Although for some stupid reason OS 4.1 for Real PowerPC Amigas does indeed emulate

does that mean more than 880k of space was available, but just not used for compatibility?

Probably because it's unreliable, and cylinder 0 is the bootblock because it's on the outside of the disk.
as you work your way to cylinder 79, each track becomes shorter, but is expected to have the same capacity.
The media is moving slower over the heads as you work your way from cylinder 0 - 79.

[diablothe2nd]

Yeah sorry bout that, was having an air-head moment :P

as for Kickart ROM location, I guess wherever you tell it to look like with UAE? in AROS there is a folder specifically for them to be placed. I've no idea about MorphOS or AOS4 on SAMs. I can only suggest you read the emulator docs. it would be in a rom file kept on the hard disk for sure though.

[TCD]

Originally Posted by xArtx

That's the answer to one question, the other is where does the emulator get the Kickstart from?

janus-UAE for AROS is based on UAE, so it'll use a kickstart file. It would be pretty impractical and limited to use the physical ROM (if it even exists in the target machine) I'd say.

[xArtx]

What about the Amiga's Kickstart location?

Whoops, you answered that!!

Impractical yes, but when I was asking about it, I didn't realise an Amiga emulating an Amiga was a practical excersise.
It appears it has some purpose.
If UAE is C, but extracting the Kick requires 68k asm, the Amiga port would demonstrate how to use both in a program.
(if it could do that).

[Leffmann]

Mixing C and assembly is trivial, and there's no need to write assembly to f.ex program the Amiga hardware or save the Kickstart ROM to disk.

A C compiler always outputs an assembly listing, and the assembler doesn't know or care if the listing was made by you or the compiler, and the linker doesn't know if the resulting object file came from your listing or the compiler's, or if it was generated by some other means.

With the exception of very specific parts of systems software, f.ex an OS kernel's need to use privileged instructions to control CPU caches and the stack, anything you write in assembly you could just write in C with less effort.

[xArtx]

A C compiler always outputs an assembly listing

Is that the exact same thing that can be compiled in assembler and run?
That sounds like a potentially faster way to learn about the custom chips,
keeping in mind the result assembler listing is unfortunate.

Bernd said something like "Then someone ported it to the Amiga so the thing could run itself".
That came across as though someone just did it for fun.
Then I think that kind of person would aim to cheat the emulation in at least those two
ways so that anyone with an Amiga could run it without providing any rom or adf file.

[Lord Aga]

What would happen if you stick an A1200 keyboard in an A600? Besides not being able to close it, of course
Would numpad work?

[demolition]

Originally Posted by Lord Aga

What would happen if you stick an A1200 keyboard in an A600? Besides not being able to close it, of course
Would numpad work?

Nothing would happen since the ribbon would not fit in the connector.

[Lord Aga]

Originally Posted by demolition

Nothing would happen since the ribbon would not fit in the connector.

Really? I thought they were the same... They look similar enough. Never measured them though

[demolition]

A600 has 30 pins, A1200 has 31 pins.

[jimbob]

Originally Posted by demolition

A600 has 30 pins, A1200 has 31 pins.

That's right, now that fellow who crammed an A1200 into an A600 case, did he just put the ribbon in offset 1 pin and the A600 keyboard worked normally?

[xArtx]

Originally Posted by Lord Aga

What would happen if you stick an A1200 keyboard in an A600? Besides not being able to close it, of course
Would numpad work?

http://eab.abime.net/nostalgia-memories/69636-top.html

Either the A500 keyboard works with a CD32, and just the connector is different,
or I had an A500 that could play AGA Pinball Fantasies... and in that case the A500 is for sale

[xArtx]

With regard to the Blitter, I'd like to know if I have it straight.

I think it is a small display buffer intended for a sprite,
and makes it possible to move the sprite around by changing the position
the small buffer is drawn, which in turn, is a way to move the sprite,
rather than actually drawing a sprite to the main video RAM and directly moving the sprite.
and that is some sort of cheat double buffering?

I imagine you already write to an off screen display buffer, and then send that to the screen at once,
making it possible to draw the next frame while the current frame is being displayed.

Is this correct?

Is the benefit that the Blitter is able to act independently of the CPU if I have everything else right?

[Mrs Beanbag]

Blitter stands for "Block Image Transfer". It is able to copy data around in Chip RAM. It can act in parallel with the CPU but you have to keep feeding it with blocks to copy.

The blitter doesn't know or care if the buffer it is copying to or from is on screen or not. That is the programmer's responsibility. In fact it can be used to copy any data at all in Chip RAM although it was designed for images and is usually used for such but you could in theory copy audio samples too.

When the blitter is used to draw "sprites" (or bobs, for "blitter objects", as they are known in this case) they are drawn directly onto a screen buffer. The blitter doesn't keep track of any objects it has drawn, the background behind them has to be redrawn when they are moved, otherwise they would leave a trail.

[mc6809e]

Originally Posted by xArtx

With regard to the Blitter, I'd like to know if I have it straight.

I think it is a small display buffer intended for a sprite,
and makes it possible to move the sprite around by changing the position
the small buffer is drawn, which in turn, is a way to move the sprite,
rather than actually drawing a sprite to the main video RAM and directly moving the sprite.
and that is some sort of cheat double buffering?

I imagine you already write to an off screen display buffer, and then send that to the screen at once,
making it possible to draw the next frame while the current frame is being displayed.

Is this correct?

Is the benefit that the Blitter is able to act independently of the CPU if I have everything else right?

What you're describing are real hardware sprites. And while the Amiga does have eight hardware sprites per scanline, it also has the blitter which works differently.

The blitter is essentially a 16-bit streaming processor. Data words flow in to the blitter from memory in up to three streams where they're logically merged and with a the result of that processing being streamed back to memory 16 bits at a time. There are also special registers that allow the blitter to stream 16-bit words from a rectangular region of a frame buffer.

There are 256 possible ways to combine the three incoming streams. Some combinations are very useful. In particular the "cookie cutter" operation can quickly place a sprite into a display buffer. Moving a sprite might consist of saving a part of the background, drawing the sprite into the framebuffer using the "cookie cutter" operation and then restoring the background before drawing the sprite again.

A similar method is used on systems with no hardware sprites where the CPU runs a program to save, copy, restore, etc sprite data but the benefit of the blitter is that it is much faster than the CPU. This is due to a several things:

1) The blitter has a barrel shifter that can shift a source any amount concurrently with word fetches. It's essentially free. The CPU can only perform a single bit shift per two cycles at best. The larger the shift value, the longer the operation on the CPU. Shifting memory even one bit takes at least eight cycles using the CPU.

2) The blitter takes two cycles to access memory while the CPU takes at least four cycles.

3) The blitter doesn't need instruction fetch cycles. Every CPU instruction takes at least four cycles for instruction fetch.

4) Yes, the blitter can run concurrently with the CPU, or rather CPU memory accesses and internal operations can occur at the same time as a blitter accesses. The first two cycles of a memory access by the CPU are spent providing Agnus with an address and not actually actually used for data movement. This means the blitter can be operating on memory while the CPU is still in the early phase of its memory access cycle.

[xArtx]

Thanks
Obviously I had some things wrong,
but I understand a bit better now.