Crazyace

Thanks for your effort Z80 definitely is a strange beast. This one is tough for it because of lots of 'random' memory access. I guess it is better on massive linear mem copy, but fails on this type of operation... It's just different. There are things that are easy to do on z80 that are more difficult to handle on 6502 ( Large stacks for example ) - but the indexing tends to suck a bit. another version ( assuming addresses are $xx00 - which is possible in optimised code ) b = >addr1 c = >addr2 d = >addr3 e = >addr4 4: ld h,b 7: ld a,(hl) 4: ld h,c 7: or (hl) 4: ld h,d 7: or (hl) 4: ld h,e 7: or (hl) 7: ld h,>addr5 7: ld (hl),a 58 cycles - not as good as the unrolled version though, but more similar to the original 6502 code. For z80 probably unrolling again ( to 4 bytes ) and abusing the stack for storing the result as well as loading might speed up a little bit more.

I was bored 19: ld a,(ix+0) 19: or (ix+1) 19: or (ix+2) 19: or (ix+3) 7: ld (hl),a 83 cycles! - way , way slower! 7: ld a,(de) 4: inc e 7: or (hl) 4: inc l 4: exx 7: or (hl) 4: inc l 4: ex de,hl 7: or (hl) 4: inc l 7: ld (bc),a 4: inc c 4: exx 67 cycles! - still slower The fastest I could think of ( combining 4 bytes ) would actually work on 2 bytes at a time 10: pop de 4: ld a,d 4: ex af,af' 4: ld a,e 10: pop hl 10: pop de 10: pop bc 4: or a,l 4: or a,e 4: or a,c 4: ex af,af' 4: or a,h 4: or a,d 4: or a,b 4: exx 7: ld (hl),a 4: inc l 4: ex af,af' 7: ld (hl),a 106 cycles for 2 bytes - still ~53 cycles per byte, but it's getter closer. ( Using the usual 2->1 divider for z80 clocks to 6502 clocks )

a = 255+(rand&2)

That's how we built the Midi-Master hardware , buffer and optoisolator chips soldered in mid air, and then expoxy'd into the SIO connector.

The cost of the cartridge port + the cost of goods of the pack in game ( and the lost royalties ) must count a bit against the cost of the CD mechanism. I still think that it would have been a win for Atari ( even going for a single speed drive rather than a double speed to further save costs ) I wonder if it would have been easy to allow the DSP to run 32 bit accesses as a master while still being 16 bit for 68k accesses?

I never knew who invented it - wikipedia says it was 1987 , documented in 1988 in Antic ( http://en.wikipedia.org/wiki/Software-driven_graphics_modes_for_the_Atari_8-bit_computers ) However Technicolour Dream came out in 1986 according to this ( http://www.atarimania.com/utility-atari-400-800-xl-xe-technicolor-dream_15870.html ) The first time I saw the effect was on a picture of a surfer , and that was way before Technicolour Dream. It relied on PAL to blend the hues of one line with the lumas of the next - NTSC doesn't have the same blending mechanics. I've got no problem if it was invented by an American though ( Colrview is a different technique though - which should be better on NTSC because of the faster refresh )

They look a lot better on my LCD TV ( in PAL - but this is much more of a PAL only technique, just like on the A8 )

Very cool demo... Just imagine what the reactions would have been if this had been seen back when the 7800 came out

I can't really imagine FlightSim actually requiring more than 16k of ram - the 5200 gives 32k linear rom, rather than 16k on the 8bit/XEGS, and the original game ran on my 800 with 48k ram.

But the full-screen interlaced graphics required 16K+ RAM especially with overscan. And then you need RAM for PM graphics stuff as well although you can use up tons of ROM space and have every combination of sprite in ROM and just toggle banks. I guess you're right , although I wouldn't expect too much of a game using those modes - and if it was for a title/screen or picture on a graphics adventure why not run it from rom. PM graphics really only need 1.25k though I still expect that all of the videos shown earlier from 8 bit games could be reproduced using the 16k ram + large rom though.

The LSR wouldn't work as it's accessing a write only address with a read. ( Although there were some VCS bank switching schemes that might have allowed that ) The logic isn't completely trivial, but people already had these schemes working on 2600 cartridges. In my opinion though, the 5200 actually has enough memory for almost any game on the 8 bit, especially if you add extra massive amounts of bank switched rom.

..that might not be correct for the 5200 startup sequence though, but the general idea is the same

The address line isn't always used as a R/W - it's limited to a small address range. So for a 5200 cart you could have rom/ram mapped like this: 4000-4fff: 4K ram bank read 5000-5fff: 4k ram bank 'write' alias 6000-7fff: 8k rom/ram bank A (read only) 8000-9fff: 8k rom/ram bank B (read only) a000-bfff: Fixed 8k rom bank and place rom / ram bank signal around bfxx, maybe like this bf00-bf7f: 4k area mapped to ram ( bank 0-3e, lo/hi 4k ) bf80-bfbf: 8k area mapped to bank A area ( bank 0-3e ) bfc0-bfff: 8k area mapped to bank B area ( bank 0-3e ) This would support a cart up to 512K , split anyway between Ram/Rom

For the 5200 I think the most important things on the expansion connector are the pokey serial lines. However I don't think the connector would be that much help for games ( I'm not sure where exactly it was physically located on the 5200 either )

As Atariksi said, only A0-A7 , A11 , and A14 are available on the expansion connector. The cartridge port has A0-A13 and 2 select lines to pick 2 16k areas.

You're simply misusing it by not spelling it 'optimise'

What about the expansion port? Anyway, isn't the lack of the phase 2 line more of a problem than read/write? (ont he VCS, usually an address line got sacrificed iirc) Phi2 is present on 2-port (and late 4-port) models though, plus any modified to support the VCS adapter, on the cart slot at least. (still no dedicated read/write line though) The expansion port has the extra signals, but you would need to use both connectors in a game. As the 2600 proves, clever engineering can even make up for the lack of a read line.

I was just going to post that My assumption is that bank switched 5200 cartridges are pretty trivial, so anything that could be done on an 8bit could be replicated exactly on a 5200 with a large enough cartridge. ( It's a pity there's no R/W line - but there's nothing stopping a 2600 style readonly/writeonly mapping of extra ram )

and this is also what the 5200 could have done http://www.youtube.com/watch?v=tmEFFp0lLzo

This is what the 5200 could have done: http://www.youtube.com/watch?v=ToIiWMf_XqU&fmt=6 and this: http://www.youtube.com/watch?v=9cnHmVV2lPA

The 7800 could easily do a Qix game , and run it at 320x200 in 4 colours, simply by using a cartridge with 16k ram.

The N64-style bilinear texture mapping is pretty slick. And like the Jaguar I, the Jag II had boatloads of programmability not present on other consoles, allowing for unique game engines. But I agree that a typical 3D game would not reach PS1 performance on the Jag II. I don't think the original Jaguar could have fit all the features of the Jag II. The chips in the Jag II used newer process tech to pack in way more transistors. John Mathieson, designer of the Jag I chipset, said they were already pushing the outer limits of ASIC process tech in 1993. If you're saying the Jag I should have come out 2 years later with more features, well... we're back on the thread topic again at last. When Atari first showed the JagII documents to the company I worked at, we already had a Sega Saturn devkit - and an import PSX had already shown what was coming ( via Ridge Racer and Toshinden ) - Given the timescale to write games, the JagII would have come out after the N64 - when the PSX and Saturn were already settled in to the market. I agree that JagII in 93 would be a miracle - but not launching anything until 95 would be just as bad for the company. A complete reorg wouldn't be a Jaguar, though , that's why I settled on the idea of just fixing the bugs - and letting the machine run more as a dual processor risc machine with a sleeping 68000 - or even no 68000 at all. John Carmack's idea of a phrase buffer on blitter out would be nice though. More software and less cost to Atari is the key though. - The machine only sold 125k units during it's lifetime , so it's a miracle that there were actually as many good games as there were! My feeling/hope would be that a 'CD' unit would have picked up more sales at the start, and given developers more confidence in the unit. It would also have allowed Atari to improve relations with reviewers, as review CD's could be sent out much more freely. In a perfect ( Atari related world ) the Jag would be released in 92, not 93

The prototype is described in the appendix of the tech guide - They mention running at 26.6MHz and the various oberon bugs. In my opinion, JagII wouldn't match either the PS1 or Saturn - in places it would be close, but really it's more what the jaguar should have been.

Everything is documented pretty well in the tech reference - Gorf was kind enough to upload it here. http://www.atariage.com/forums/topic/15557-jaguar-ii-tech-ref/page__view__findpost__p__1456621 All of the system parts have full 64 bit access to memory though ... but it's less important for the sound dsp, as it has it's own ram to fetch samples from ( 8 bit or even 4 bit to save costs ) The memory is faster - 33MHz rather than 26, but it's still cheap dram.

Are you talking about the existing jag II prototype or the specs for the final design? Jag II specs. There was no prototype that included the "C-friendly" JagRISC. That chip design was unfinished. The only chip that made it to early prototype was the graphics chip. The Jag II had a lot of raw power -- but so did the Jag. Like the Jag, it wasn't very accessible to mortal programmers. Looking a bit at the Jag II chipset, it doesn't seem like they shifted towards the mainstream mass market as much as they could have in terms of graphics, they seemed to focus on a proportional succession of the Jaguar's strengths instead. (ignoring the C friendly CPU bit for the moment) My understanding is a bit limited, but from what I can get out of the technical description here: http://www.atarimuseum.com/videogames/consoles/jaguar/jag2specs.html For one thing, the addition of phong shading seems a bit unnecessary, though I'm not sure about the design as a whole. It seems like they're still relying on the custom RISC MPUs to perform the 3D math and rasterize triangles. (unless I'm mistaken, the blitter can't draw geometric primitives on its own) Those specs seems wildly inflated compared to what I was told at the time, and also the info in the midsummer tech guide. There's definitely no phong shading in hardware