Jump to content

Recommended Posts

I was wondering, with all the different cartridge types, what defines the location where the storage is banked into? Is the logic in the Atari hardware, the OS or the cartridge itself?

 

On the off-chance it is the latter, would it in theory be possible to have a cartridge which only banks a few bytes into the colour registers, allowing quick changes of colour palettes?

 

Probably not possible, but just thinking outside of the box.

Share this post


Link to post
Share on other sites

Carts can only exist between $8000-$BFFF and $D500-$D5FF.

There's 13 address lines supplied which allows 8K of address selection.

The S4 and S5 lines allow selection of the upper and lower 8K of the cart address space.

The CCTL line allows selecting the $D5xx addresses.

 

Not possible to do tricks like a blit into colour registers etc.

The banking scheme if present is decided mostly by the cartridge - and is within the realm of possibilities above.

 

Most banking and control schemes simply use the $D5xx addresses in some way. In some cases any access type, in others an access or write to particular address range, and in others a bitsetting to an exact location.

 

Also we have modern day flash carts. In most cases they use writes to specific addresses in the ROM area to initiate wrtite block sequences. You can look up datasheets for some of the chips used and correlate what needs to happen on the Atari side from them.

  • Like 2

Share this post


Link to post
Share on other sites

Cartridges are banked into fixed locations defined in the MMU.

8000-9FFF

A000-BFFF

When these areas are accessed ram is disabled so the cartridge responds instead.

 

Colour registers are internal to gtia, enabled at D0xx. It does not access the register from ram, so even if the memory could be mapped there it would not do anything.

  • Like 2

Share this post


Link to post
Share on other sites

Thank you both!

 

I was just wondering on the off-chance I'd dreamt up a mad new way of quickly changing palettes.

 

I knew that the existing cartridge systems tended to use the same areas of memory, but wasn't sure if this was due to some convention (i.e. Changeable) or through technological limits of the A8 architecture.

 

Have a good day ahead!

Share this post


Link to post
Share on other sites

VBXE can't do it either, sadly. It's blitter is restricted to it's own VRam only. It can't even reload it's own registers (I think Amiga can hit all of it's HW regs, not sure about ST).

Share this post


Link to post
Share on other sites

That's it... blitter restricted to chip memory and copper can hit the hardware, though copper has much tighter limitations on how much it can do in a scanline.

Share this post


Link to post
Share on other sites

I was just wondering on the off-chance I'd dreamt up a mad new way of quickly changing palettes.

 

With an UNO-Cart you have the freedom to tweak the firmware to your hearts content.

 

So in theory you can 'expose' a small code routine in either the cart memory area or cart address bus ($d5xx) that you can hook into a VBI or DLI.

Within there, the new colour values can be applied to the palette registers.

  • Like 3

Share this post


Link to post
Share on other sites

 

With an UNO-Cart you have the freedom to tweak the firmware to your hearts content.

 

So in theory you can 'expose' a small code routine in either the cart memory area or cart address bus ($d5xx) that you can hook into a VBI or DLI.

Within there, the new colour values can be applied to the palette registers.

 

And if I understand it correctly, the Uno cart's processor can also be used as a coprocessor, that is, if the firmware was written. :-)

  • Like 2

Share this post


Link to post
Share on other sites

Interesting! So if we also had a version of Rastaconverter which only decided which pixels were allocated to pmgs and which were normal playfield colours, this could be a way of getting higher quality pictures for people who already own the hardware?

Share this post


Link to post
Share on other sites

In theory it could be a dynamic code generator and we could get higher capability games like on the 2600 with stuff like PMG repeating on a line.

 

That's additional to normal coprocessor benefits such as it doing lots of softsprite work in the background.

  • Like 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...