Jump to content

Crazyace

Members
  • Posts

    1,033
  • Joined

  • Last visited

Contact / Social Media

Profile Information

  • Gender
    Male
  • Location
    London / HK / Tokyo / San Fransisco
  • Interests
    2600 programming<br />All things Atari..<br />PS3 optimisation

Recent Profile Visitors

14,716 profile views

Crazyace's Achievements

Stargunner

Stargunner (7/9)

52

Reputation

  1. Yes, a fast page mode would have been better ( The Archimedes VIDC used burst mode as well to fetch video data ) With that ( as the falcon proved ) you wouldn't need a 64 bit memory bus - in a perfect world there wouldn't be a TT in 1990. but instead a 1040TT in 89 with VGA compatible output ( 640x480 16 colour and 320x240 256 colour on monitor or interlaced TV ) , no blitter but just a 16MHz 68020 - all priced at STe prices ( Or the $999 magic number ) Zooming out could show the whole 512x512 bitmap on screen at once. It did seem strange and I wonder if there was some overlap from Ricoh with what they eventually offered to Nintendo for SNES mode 7. For Panther I think rendering to a framebuffer would complicate things a lot - especially with the sprite scaling to the linebuffer. ( The saturn was a mess in that way and it was a lot newer ) You basically end up with the slipstream/jaguar blitter and your pixel cost is 3x at worst ( Read pixel, write to frame buffer, read frame buffer to scanout ) At least with the Jaguar it was getting to the point where the blitter was getting fast enough to compete. Rotated sprites would have been nice - but you would lose the linear memory read. ( It was mitigated on the PS1 by having a texture cache )
  2. The C16 has a great colour attribute system that could have been used to enhance Antic/GTIA on the 8 bits. By fetching colour bytes on a 2nd character line you would have the enhanced attributes, and by taking 3 lines ( charset, plus 2 colour bytes ) you could have independent fg/background colours per character cell , or even 3 independant colours per 8x4 multicolour cell, Although it's easy to think of MARIA as a computer chip it has a few real limitations, in particular the character mode limits all of the characters to the same pallette - making it difficult to have a 40 column 8 colour text mode. A tweak to the antic/gtia would have been better. Or even faster memory - on the BBC micro the memory runs at 4MHz , so even in highres ( 80bytes/line ) graphics modes the 6502 runs at full speed.. with the 8 bit allowing 6502 stalls you could support 160bytes ( for 80col chars, or high res and better player missiles )
  3. The super xe doc is interesting - it isn't a cheap console ( the 512x512 4bit rotation buffer needs 128k ram just for itself ) , and just getting rotation working with the 250ns ram needs both banks to be fetching seperate 4 bit nibbles per cycle ( Hence the 100% bus usage ) - by having a line scroll ( and column scroll ) it's much more like the SNES , and the faster SNES ram ( along with 256 pixel display ) allows 2 banks to fetch character and pixel - making mode 7 practical.
  4. I think SIPPs were still only 30pin - and the TT was 64 bit - Atari could have just had extra sockets ( like the 1040st having 32 ram chips for 2 banks ) - to allow expansion.
  5. For panther cost would have been everything - in 1991 the Genesis was $149 with Sonic , and if Atari were pushing panther as a 7800 successor it would have to be aggressively priced. In the end though Jaguar just outclassed it on every level and it would have struggled to compete against Sega and Nintendo 16 bit machines. From the netlist for the game shifter (panther chip) it would set a complete run at once ( using the begin address and end address to set a 320 bit wide load mask for the single 5 bit input ) - so long runs would be quick. It would be interesting to write some tests to figure out what kind of polygon fill performance might have been supported by using the run length objects. On your other points - a 16MHz 68020 TT ( no FPU ) with 512k memory (64K by 64bits would be possible using 64k4bit dram) would have been the best machine to release instead of the 520STe in 89 - just tweaking the modes to be TV and VGA compatible ( so 320x240 256colour and 640x240 16colour for TV as well as VGA ) would give the graphics boost needed along with the better cpu. 89 might have been too early to support memory upgrades though - 2 simm72s for expansion would be great but I dont think they appeared till 1990.
  6. Existing PC's would be too expensive - Panther was super cheap ( like the 7800 ) and on paper had the sprite scaling features that would rival the NeoGeo. ( It was also much more powerful than the konix , although only 32 colours was a big limit compared to SNES/Megadrive/PC Engine )
  7. I think that the panther also would have a problem due to the lack of colour - the line buffer only supports 32 colours per line - less than the 64 colours ( more with shadow/highlight ) on MegaDrive. Also a 16 pixel sprite would be 4 longs in ramfor the control (8 cycles ) + 4 words of ROM data ( 16 cycles ) - given 1024 cycles per line this allows 42 sprites per line - more than the MegaDrive, but without any background screens...
  8. This website is quite interesting http://www.amigahistory.plus.com/sales.html It shows the breakdown as almost 10 to 1 in favour of the cheap A500 model, which just shows how the market had moved on The ST had the foresight to implement the b/w mode - that was a failing of the amiga tying it completely to NTSC - given the price of the A1000 support of a workstation monitor ( No VGA in 1985 ) output with non interlaced 640x480 @ 60Hz would have been amazing - even if it was limited to 4 colours it would still be better than the ST. Maybe the Amiga would have been better as a bare bones machine - a super C64 rather than a new multitasking windowed machine. As well as the games, lot's of the definiing titles such as DPAINT weren't really windowed apps anyway
  9. If the Amiga had shipped with mixed chip and fast ram it might have helped things a bit - the original A1000 could have been 256K fast plus 256K chip - and that would allow the 640x240 16 colour modes to be used without slowing down the cpu at all. It would have been a lot easier to make new models with faster cpu's - or even move the video circuitry onto a card in the A2000's to more directly compete with the IBM PC
  10. You could look here I guess: http://atariage.com/forums/topic/15557-jaguar-ii-tech-ref/
  11. Expansion on cart would be nice - It might actually be better to only have 'chip rom' instead , The Amiga 1000 used up to four banks of 128K chip ram ( 2 on board, 2 in expansion ) so something similar could be used to allow 3 possible 128k areas on the cart.
  12. Hi Carlsson, I'm not worried about the price too much. It was being designed as a console, so I'm just assuming it must have been possible to price as one.
  13. Having FAST and CHIP on the cart port would complicate things. I was thinking that 68k only rom could be slow, and still work at the same time as chipset ram accesses
  14. Hi Bill, I'm not making any assumptions really, just following up the comments by one of the original designers ( Joe Decuir in the video ) about the Amiga being designed for 32k as a console ( I'm guessing that 128K was the computer version shown in 1984 ). Whether an Amiga computer from Commodore would actually happen if the console had been picked up is a completely different question. It's not as if the NES sold amazingly well in it's first year anyway - and that was in a market where it was technically superior. In 1985 Nintendo didn't have all of the US developers locked in. Also an Amiga console may not have been a commodore product ( If Commodore had announced a console they would have produced software - after all, there would be no intuition or Amigados required, so companies like EA would have been offered gamedev opportunities with the lorraine devkits in baremetal mode ) There's no argument that it would win , but it would be in the market in 1985, with way superior technology - at the same time as the initial NES launch with ROB and duckhunt Cart memory as chip would be nice - but I think better as 'fast', If code is running from ROM there wouldn't be as many stalls, I was thinking that graphics would be copied from ROM to the 32k ram via movem.l sequences - and only the actual writes would actually stall, ( after all on the ST the CPU handles all graphics, and still there were games running at 60Hz )
×
×
  • Create New...