Amiga questions you've always been too embarrassed to ask

[diablothe2nd]

would you suggest i take my pre rendered background and break it up into 64x64 tiles. then simply tell it to load only the tiles about to come into view? EDIT - and discard the ones that just left

[Mrs Beanbag]

Originally Posted by diablothe2nd

would you suggest i take my pre rendered background and break it up into 64x64 tiles. then simply tell it to load only the tiles about to come into view? EDIT - and discard the ones that just left

As in, load them from disk? Usually you would store all the tiles in Chip RAM and draw them on the screen when needed. 16x16 and 32x32 are typical sizes for tiles but you could use 64x64.

A common trick is to use the Copper to reset the bitplane pointers back to the top of the screen so it "wraps round" vertically. Horizontally you don't need to worry about because that wraps round anyway. Just make sure the screen has a few spare lines at the bottom. That way you can scroll around a huge virtual area, and only draw the tiles at the edge as they come into view.

[diablothe2nd]

ok. it seems to me that storing the whole track as a single image would be wasteful. i presume the trick would be to try and repeat certain tiles a few times so it only uses that tile once on a tilemap, but duplicates it with the blitter?

EDIT sorry, i meant "track" to be the tilemap. i've got a racing game in mind so said track instead.

[Mrs Beanbag]

Originally Posted by diablothe2nd

ok. it seems to me that storing the whole track as a single image would be wasteful. i presume the trick would be to try and repeat certain tiles a few times so it only uses that tile once on a tilemap, but duplicates it with the blitter?

Yes you would use the Blitter to copy it onto the visible screen.

One thing I intend to try in future is not to use "tiles" as such but simply a source image, from which you can copy a 32x32 tile from anywhere on the tile sheet instead of being restricted to a grid, which would give a lot more design freedom and mitigate the obvious "tiled" look.

[diablothe2nd]

thanks for the clarification Mrs B! see this is why i post daft questions, cos it leads to banging heads together and helps me take baby steps in the right direction

as for the point about grids... call me crazy but i thought that was the case anyway? i'm no programmer but i thought you could specify regions from a tilemap for things like animations etc. say you have a 64x64 bob, but your character only occupies 63x63 pixels for a couple of frames, if you created a sprite sheet, with only 1 pixel between each image as opposed to two, you could say frame 1 is from 0 to 63 pixels, but frame 2 is from 62 to 126 pixels... thus if you have alot of bob frames you can save a few kb by squishing the animation down and saving pixels?

EDIT i've had a few beers and completely fluffed my maths up there LOL but i'll assume you know what i'm getting at lol

[Mrs Beanbag]

Well you could do that if you were short on space, but bear in mind that the Blitter operates on a per-word basis so if your source images aren't horizontally aligned to 16 pixel boundaries it has to process more data than it otherwise would. Besides if your bobs are all different sizes you will have a task trying to fit them neatly into a rectangular image without any unused space.

Bobs are different from tiles anyway because they are all different sizes and can appear anywhere. Tiles are all the same size and are always placed on a grid on the visible screen.

But what I mean is, usually you would just have a set of tiles accessed by index number. But you could access them instead by X and Y co-ordinate on the source image, that way you could use tiles that overlap on the source image and increase the variety, perhaps even reducing the space usage if several tiles have parts in common.

Suppose you had two tiles A and B next to each other on the tilesheet like so:

AABB
AABB

So if you wanted you could also copy from the middle and get a tile like so:

AB
AB

three tiles for the price of two!

[diablothe2nd]

i think we're talking bout similar tactics, save for me talking about bobs.

say you have a sprite sheet, and you have frames set 16 pixels apart. but some of them dont occupy the full 16 pixels, could you not do something like this:

p = coloured pixel
- = transparency

ppppppppppppppp--pppppppppppppp-

you would flag it as tile one from pixel 1-16 and 17 to 32

while if you remove one of the blank vertical fields to make

ppppppppppppppp-pppppppppppppp-

and call the blitter to look for 1-16 for first image and 16-31 for the second? thus saving one vertical pixel line?

[Mrs Beanbag]

But Blitting pixels 16-31 doesn't match word boundaries, so you'd have to blit the full 1-32, doing shifts and masks. So you'd save a pixel but double the work for the blitter.

Anyway your sprite sheet has to be a multiple of 16 pixels wide anyway so it's unlikely you'd be able to gain very much.

What I'm talking about is having tile 1 occupy pixels 1-32, tile 2 occupy pixels 17-48, and tile 3 occupy 33-64. So they overlap on the image, and you'd be able to place objects on your map that appear not to align to the tile geometry.

(p.s. I wouldn't be surprised if this got moved to the programming threads area)

[diablothe2nd]

so you can overlap flags for coords on tiles, but not bobs?

[diablothe2nd]

disregard that question. i think i'm now at the point of too many beers i'll come back tomorrow

[Mrs Beanbag]

Originally Posted by diablothe2nd

so you can overlap flags for coords on tiles, but not bobs?

I'm talking about the actual images overlapping. Tiles aren't transparent and are always the same width. Supposing you had a map of 32x32 tiles and a tilesheet with a tree that spans a large block of tiles. Well you could offset that tree on the map by 16 pixels, without having to have another whole set of tiles to represent the shifted tree.

[diablothe2nd]

ahhhhhh! i see!



on an off topic point, we'e freaking spoiled these days. i was playing with BlitzPlus for windows and due to having 16gb ram i never had to think this way. it gives me so much more respect fpr amiga devs now realising what they had/have to do to stay within the constraints of an unexpanded amiga.

[mc6809e]

Originally Posted by Mrs Beanbag

A common trick is to use the Copper to reset the bitplane pointers back to the top of the screen so it "wraps round" vertically. Horizontally you don't need to worry about because that wraps round anyway. Just make sure the screen has a few spare lines at the bottom. That way you can scroll around a huge virtual area, and only draw the tiles at the edge as they come into view.

Ever try this with HAM? Pixels from the 16-color palette could be used for the left edges of tiles and with HAM for the rest of the tile. Copper could even modify the palette to improve things further.

Bobs would be almost impossible, but hardware sprites are still available in HAM -- though one black sprite would be used to mask artifacts on the left edge of the display area if doing an 8-way scroller.

Maybe there's enough CPU time to patch the playfield if there's a small number of bobs. Did you ever raster-time the 8-way scroller code including the blits for the edges?

[OddbOd]

Originally Posted by amigafan33

Hi, I'm new here. I just wanted to know why the amiga had a power button on the power brick but no power button on the machine itself or on keyboard, while the c64 had its power switch on the side of the machine, and PCs have both a power supply switch AND a power button on the machine?

There is no absolute answer to this question but I would guess that it's because the 64 had no standard soft reset mechanism (you had to wire in a reset button yourself) whereas the Amiga did, turning the computer off and back on again was the "normal" method of restarting the 64. As for PCs, the ones that were available when the 64 & Amiga were developed did not have front panel power buttons (that wasn't common until the 90s) only reset and sometimes a clock frequency switch, it was still the norm to turn the machine off at the power supply.

Originally Posted by lordofchaos

I have a question. Who is "Fungus The Bogeyman"?

A well known British children's book character from the 70s that was ripped off some years later by William Steig to create Shrek (this is not true though there are some obvious similarities between the two characters).

Originally Posted by Toni Wilen

This is different bug. It makes extra PAL area completely inaccessible.

Was that the PAL machine reboots in 60Hz bug? I still don't understood the exact circumstances under which this happens but would be interested to find out.

Originally Posted by Mrs Beanbag

There is a hardware register starting in ECS that you can set a bit to switch between 50Hz and 60Hz.

Is it time to muddy the waters by pointing out that 50Hz vs 60Hz refresh is not that same thing as PAL vs NTSC output?

[Mrs Beanbag]

one thing that just occurred to me... can you blit into hardware registers? For instance to copy a palette from Chip RAM into the registers? Could be powerful if so, because copper can control the blitter...

@mc6809e:
interesting idea about HAM scrolling, I don't know what happens to the edge of a HAM screen if you use the scroll registers, does it still process the colour values that are not actually visible off the side of the screen?

[mc6809e]

Originally Posted by Mrs Beanbag

one thing that just occurred to me... can you blit into hardware registers? For instance to copy a palette from Chip RAM into the registers? Could be powerful if so, because copper can control the blitter...

Not directly. What you have to do is blit into a copper list that does the writes.

In theory it should be possible to turn the blitter into a shift and add multiplier this way. This might be useful if the CPU is already doing many multiplies and not taking up many bus cycles.

Rough sketch (lots of holes -- not tried):

We already know how to shift memory with the blitter, but for addition, fill part of memory with values equal to the address of the words themselves shifted one right. In other words, location 0 holds 0. Location 2 holds 1. Location 1024 holds 512, etc, etc. Addition is then possible by loading APTR with one value and AMOD with another, both values preshifted one left. Then blit one word with just A channel active. This adds APTR and AMOD. Then do copy from A->D with A shifted one right. The destination will then have the result of the add.

Combining shifting and adding allows for multiplication.

This can all be done (slowly) with the CPU controlling the blitter, but for speed, this can be controlled by the copper. The trick is to point DPTR into the copper list so that the copper can write the value back to APTR for the next iteration. The copper will spend a lot of time waiting for the blitter and writes will have to be done into the copper instructions just ahead of the current copper pointer.

It should even be theoretically possible to turn the blitter+copper into a processor that is Turing-complete using a similar technique.

With addition and shifting, much is possible, but conditional execution is still needed. Luckily line mode provides the answer.

By controlling the sign bit, we can conditionally add AMOD or BMOD to APTR. This means the sign bit can hold the results of operations similar to a condition codes register and program flow can be altered by using AMOD and BMOD to hold addresses of jump destinations. If APTR is clear, then the sign bit controls which of AMOD or BMOD ends up in APTR. The result again writte into the copper list instruction doing a write to COPLC. Strobing then transfers control to a new location.

I'm sure the details of making such a thing work are incredibly complex, but possible in theory.

@mc6809e:
interesting idea about HAM scrolling, I don't know what happens to the edge of a HAM screen if you use the scroll registers, does it still process the colour values that are not actually visible off the side of the screen?[/QUOTE]

I think on the left edge HAM takes the color the of the background color if the first pixel is a modification pixel.

[Jope]

Originally Posted by amigafan33

Hi, I'm new here. I just wanted to know why the amiga had a power button on the power brick but no power button on the machine itself or on keyboard, while the c64 had its power switch on the side of the machine, and PCs have both a power supply switch AND a power button on the machine?

The C-64's power switch only has two voltages to toggle. The wedge cased Amiga has three. Big box Amigas have even more wires that the switch should affect. The standard at the time for power supplies that have that many voltages is to have a mains power switch that cuts all power to the PSU.

Big box Amigas have the power supply in the computer's case, thus the mains switch is also on the case within reach.

PCs also used to have a mains switch before the ATX standard came along. But again, PSU in the computer case so the switch could be located within easy reach.

With ATX, someone invented a software power switch for the PC, but most power supplies still opted to have a mains switch too for those times when you need to have the computer totally powerless. Now less conveniently located on the PSU itself at the back of the machine.

But really, it's because of the amount of wires the switch would have to disconnect and as a happy coincidence you also improve PSU lifetime by totally disconnecting it from the mains power when you flick the switch.

[Mrs Beanbag]

@mc6809e:

You can add numbers using the blitter much more directly than that, I thought that was the original intended purpose of fill mode - to propagate the carry bit.

[xArtx]

It might sound like another odd one...
If I remember correctly the Amiga 500 has two LEDs in a single package
to give the appearance of a single LED that is longer than normal.

When the power LEDs go out, do they both go off, or does one LED go off
giving the appearance of the single long LED just going half as bright?
Or does this behaviour change depending on the particular model keyboard?

I also remember that there are red/green and green/orange colour
combinations, and wonder if that is tied to any particular models?

[roy bates]

Originally Posted by xArtx

It might sound like another odd one...
If I remember correctly the Amiga 500 has two LEDs in a single package
to give the appearance of a single LED that is longer than normal.

When the power LEDs go out, do they both go off, or does one LED go off
giving the appearance of the single long LED just going half as bright?
Or does this behaviour change depending on the particular model keyboard?

I also remember that there are red/green and green/orange colour
combinations, and wonder if that is tied to any particular models?

if one goes off they both go off if they didnt you would still see one on.
as far a know to set a led half bright just lower the voltage going to it.

as for the different coloured leds,and led is an led you can put any colour in there just like the manufacturer did.