using the unused/duplicated mem. locations in the A8 hardware registers

[carmel_andrews]

Following on from something i read in Bob Du Hamels 'Hardware Reference Manual', in which he said (or at least it was printed) that the Atari 8bit memory map could handle multiple iterations of the various Atari personality IC's (i.e pokey, antic, gtia, pia)

 

Not exactly sure if it's possible 'electronically' to using the exact number of Atari personality chips as mentioned in the relevent piece within the manual, but i guess since stereo pokey (or gumby to give it it's orig. name) and bob wooley's dual antic upgrade (from way back when) indicates that you could possibly use say 2 or 3 iterations of the various atari personality IC's in a A8 upgrade

 

 

However, seeming as though each iteration of each personality IC is just grabbing x number of unused/duplicated locations, within that IC's given memory map area, rather then just have multiple iterations (equal to the numbers stated in the relevent piece within the mentioned manual), what about say an FPGA chip (for ea. personality IC) or an updated P.A.G/PIA chips but with something useful taking up the unused/duplicated memory areas of the respective personality IC's

 

In regards to the FPGA/updated P.A.G/PIA IC approach, you could program the unused area's of ea. personality chip to doing something useful, like addit. sound channels, ADSR, ring modulation/pcm or sid/amy 'alike' features (or features similar to said IC's), or for the ANTIC/GTIA locations, to program them to handle bigger PM's, more pm's, more colours, high resolution etc etc, reprogramable gfx resolutions (like in the later iteration of the msx series) vertical/horiz. screen splits (like the shifter II does) and possibly blitter like features and for the PIA locations, additional registers to handle better memory addressing/bank switching capabilities (a lot better then say $D301)

 

I think this apprach to improving atari's gfx/sound and other hardware abilities would be a better approach then say VBXE or sticking a sid chip/gravis ultrasound board on a chip into an A8, since at least you are keeping faith with the atari hardware and merely extending it's abilities then using someone elses hardware (i.e texas instruments if its a VBXE or commodore if its a SID chip) in the A8

 

Please note, i've nothing against the likes of VBXE/SID cart etc, nice idea, good products and takes the A8 to new levels of hardware features, but i just prefer keeping faith with the Atari IC's we already have and just doing something useful with the unused/duplicated locations within those Atari IC's giving those IC's capabilities/features similar to the likes of sid/gravis ultrasound or the vbxe

[Rybags]

Just because some new hardware uses similar locations to a similar function custom chip doesn't mean it's "keeping the faith" in any way moreso than something like VBXE or Covox that might use $D5xx or $D6xx.

 

By using the same memory page, you instantly invite incompatabilities because some software out there uses the mirrored locations instead of the official ones as a means of throwing off hacking attempts.

 

The way I'd do things - imagine an Antic was developed that allowed dual PAL/NTSC among other things:

- have a pair of "unlock" write registers, mapped somewhere like $D4C0. Unless you store a specific byte in each, you get the mirrored access as normal.

- once unlocked, you then get the extra registers, mapped $D410-$D47F/whatever.

 

 

Also - I believe the idea is already in use, Ultra 1 Meg uses a couple of locations in page $D3.

Edited October 25, 2011 by Rybags

[sloopy]

altho i think they idea of having a 'key' to unlock mirrored memory addresses is a decent one, i think the problem should be fixed, not a solution to 'work around' the poor programming practice... altho this is alot of work fixing the software that does this, its much more reasonable as we should learn from history... Microsoft Word 4.x was so large, not because of features, but because of all the workarounds it had to incorporate for the various OS's, hardware, and drivers it had to deal with.

 

when the 400/800 were designed, memory was expensive, IC's were expensive, so not decoding the i/o pages down made sense. But now that we are running out of room (heh yeah we did that in nineteen eighty what?) working around 'poor programming practices' from 25 years ago is a bad idea in my opinion, these pieces of software need to be modified for other 'anti-cracker' methods, so what is one more 'security measure' removed, especially considering the general ease of it compared to hardware change?

 

sloopy.

[Bryan]

Detecting the first copy of each IO range is pretty easy. Use a multi-input OR gate to make sure all undecoded address lines are 0, or better yet use a one-of-x demux to make several select lines available. Then mix that into the address decoding PAL. Of course, Atari wasn't concerned with absolute economy of the memory map in 197x. A 48K machine was pretty extravagant.