Crazyace

Maybe, V=ref Copy blit , XOR with (255 XOR v ) - so dest is FF for V values Blit dest over itself Conditional AND blit ( XOR 255 ) to give (NOT dest) AND dest if dest!=255

Yes NRV sorry about that - I typed too quickly , but testing a power of 2 isnt the problem posed anyway. Rybags wants bit to byte/pixel expansion for graphics.

NRV's method wouldn't actually work though - as all the original values are powers of 2 - and it doesn't distinguish between them , as v&(v-1) == v when v=2^x. I think the bli_zoom would just duplicate the byte value 8 times - it's not working on bits

I looked quickly at the VBXE doc , and it can be two passes non destructively - allowing you to run 8 times on the same data to get full bit to byte expansion. ( by blitting individual columns ) Blitter Copy src->dest , AND (2^Bit), XOR (NOT(2^Bit) Blitter AND src->dest(conditional) , AND(2^Bit) , XOR (2^Bit)

or maybe 2 blits if you destroy the original ( Again for 0x80 case ) Blit with OR constant $7f - ( 0,$80 becomes $7f,$ff ) Blit with conditional ( and $80,xor $80 ) and AND ( $80 AND $7f gives 0 , $ff left unchanged )

it's impossible using just wrapped binary arithmetic - but I think you might be able to use 3 passes with vbxe ( using $80 example ) 1: Fill dest with constant $7f 2: Conditionally copy ( and = $80,xor = $80 ) - so 0 pixels are $80 , and $80 pixels are left as $7f 3: Xor dest with const $80

Tom contains the blitter, gpu, and object processor - and Jerry is the audio dsp.

That was way back then when everyone was talking about a 68020 going in the system - I thought the IBM 486SLC ( or even the older 386SLC ) would have made a better cpu due to it's larger cache. I changed my mind about 'throwing more chips into the design' and suggested no 68k at all and single speed CD build in as I think that would have been much more important to the success than having a slightly more powerful jaguar. Finally I thought about the Object processor and Jerry DSP and exactly how important they were - and I decided that in my opinion they were overkill, as Jaguar audio rarely sounded much better than Amiga anyway - and very few games actually used the object processor in ways that couldn't be achieved just with the blitter. If there was only Tom - no 68k or Jerry - on the system with a CD Atari may even have managed to launch at a similar pricepoint to the original Jaguar - and things might have been very different

Seeing this crop up again I started thinking about what use was Jerry. Given that the OP/2D sprite system came from the panther chipset if Flare had dumped that and just used a fixed 320x240 CRY output they would have saved a lot of silicon in Tom , maybe enough to put in a simple FIFO driven DAC ( Atari STe style, but 16 bit ) - after all if you add up the pallette and linebuffers that's almost another 4K of ram. Freeing that might allow the blitter to be slightly more functional ( texture mapping colour expansion at least ) Atari would then end up with almost a perfect single chip console - just Tom, and dram ....

still sounds like a voxel space - just one that's ray cast in perspective rather than orthographic. - However it's seems to be an impractical scheme to use on a Jaguar - if you are using the OP to scale layers the number of full screens will drop even further ( 5 or 6 maybe ) I guess you might want to encode all of the scenes in some kind of sparse tree structure to help accelerate things, but it seems a little bit static to me. Anyway I'd love to see one day. ( I have several things I need to finish on Jag that I just never seem to find the time for, so I'm always impressed by any project that shows up, software or even hardware mod like your jagcd )

It sounds a bit like a layered voxel scene - but the memory costs would be exorbitant. For your example ( using 8 bits per pixel to save memory ) a single 1280x800 layer would need 1000KB of storage - How many layers would you have - 8,16, or more? Also how are you going to generate these images in the first place. And rendering would be expensive - for every pixel you effectively either paint all of the layers from back to front - or 'raycast' from front to back to find the first non opaque pixel, In the first case the OP is the best way, and I think you'll run out of b/w after 10 layers of 320 pixels. Doing the other way would involve gpu - and be a lot slower ( at least a load/cmp/jump per pixel per layer ) - so you might have trouble with even half that many layers. Also - if you really want full 3d you have to have a real volume ( 1024x1024x1024 ) to allow any viewing direction. Of course you might be talking about something simpler, like the scaled sprite compositing made famous by Sega ( and used to great effect in Super Burnout ) - with that the Jaguar can shine, but it's not really full 3D.

What do you mean by a pixel scene generator?

The starfighter A7000 comment was compared to how it looks on the older A3010 ( The A7000 came out in 1995 - after the Jaguar ) Regarding the 2D comparision SuperBurnout is really nice on the Jaguar - but dont think that Outrun is really stretching the Saturn technically. You might want to compare PowerDrift - as that is slightly more technical - or trying looking at StreetRacer's saturn version compared to Atari Karts. Anyway my comment wasn't really about Starfighter - just the capabilities of each machine. ( I think Capture the flag and Rescue on Fractalus showed the power of the 8bit way way before Yoomp etc )

Everyone is missing something, and lots of things seem obvious in hindsight - that's what's fun I disagree with you on the "they didn't have the money" panacea though - that's an extremely lazy conclusion in some respects. It's also nice that amongst the hyperbola there's often various nuggets that crop up in the comparision threads ( perhaps not this one quite as much though ) - even the Atari vs C64 one had some cool info ( and pics ) Maybe in 10-15 years people will play what-if's on info about PS2 or PS3 that mirror some of the what-if's the original engineers went through in design. ( At the time, looking at 3D0 and Jaguar from the point of view of the devkits and info exposed then , it was obvious that the 3D0 was vastly better than the jaguar - but it was way more expensive , and the Jaguar was still way more powerful than the SNES/Genesis. )

Are you likely to have an epub or Kindle version?

I'm assuming a 100k order ( even factored over an 18month period ) would achieve a better price than a 100 off order ( The $487 number ) , that's the experience I've had with electronics orders before. ( I'll take your word on napkins and toiletpaper ) I'm also assuming the 12MHz part would be cheaper than the 16MHz part ( due to binning ) I was only pointing out that the cpu cost is actually not the majority of the costs in the workstation market ( As you mentioned that being the only market for the chip ) - it was just a bit of info that seemed interesting. This is all fantasy - take the workstation down to the 'home' workstation ( homestation ) I dont think that the R&D costs of a 68020 machine would be anymore than those of the 68000 - only the chip costs. Why do you think it would increase from 1 to 2 years anyway? Regarding the 'grass roots' support - that would be offset by the fact that the resultant machine would be way more comparable with Amiga / Mac / and PC - and also way more future proof.. ( In hindsight ) ( I dont think the ST really hit 'consumer' until the 520STFM model came out anyway )

I tracked this down ( processortimeline.info/proc1980.htm ) which prices the 16MHz 68020 at $487 - I'm assuming a cheaper price for bulk ( and 12MHz ) . Interestingly I tracked a Workstation launch here: http://books.google....epage&q&f=false This is expensive, but prices the 68020 workstation product at roughly the same price as competitors 68010 products - so I dont think the market is quite the same as that of the more cut throat ST/Amiga.

The 68020 was just being introduced in 1984 (it had it's first power up test that March), and was not in production yet by the time the ST was being designed across Apr-Jul. Likewise the cost would have been way more prohibitive than that for a brand new chip just being released (with no second source), there would have been no way to meet the desired low end margin. There's a reason why 68020's were first used in 1985 - in high end workstations - and then in the high end Mac II in 1987. Guys, hind site is not 20/20 if you're not going by the actual facts. Well as I said I'd forgo the extreme low end margin to get the processor in , and increase the price to the consumer. ( By increase price I mean at least $500 - to offset the very high cost of a 68020 at 12MHz ) With a faster cpu and better professional graphics you would pull in more of the PC/workstation/mac crowd - price cuts etc could follow eventually , and the product would be much more future proof. ( I know that the 020 appeared in workstations first - but I expect Jack could have got a good price from Motorola based on quantity ) Wasnt there a rumour anyway about the NS32032 being the cpu anyway?

I'd have made the ST a higher end system, while still trying to keep the price. Put a 68020 at 12MHz in with 256k of ram ( 32 bit wide ) - and have a full expansion bus/slot rather than the cartridge port. Have the graphics steal cycles ( a la 800 ) rather than be interleaved - and only have 256 colours with no pallette ( 2:2:2:2 RGBI ) with support for EGA style monitors as well as TV. Offer 160,320,640 X and 480,240,120 Y - with a Antic style linebuffer to allow TV and line doubled monitor use. A 68020 might bump the initial price up by $200 or even $300 , but price would still drop , and this ST would be way more competitive with the Amiga, and also the Mac and PC.

Toot your own horn as much as you like - the Skunkboard is the best thing to come out for the Jaguar

Sure, but CLUT RAM is also the slowest RAM on TOM, so you probably don't want to blit TO it. It takes 8 cycles to read back one 64-bit phrase from CLUT, which kills any benefit. The cycle counts work out about the same for SRAM->CLUT->DRAM as DRAM->DRAM, except with the CLUT you waste even more time setting up the extra blits. Blitter setup is already so expensive that it is a major bottleneck with small polygons, and SRAM->CLUT->DRAM means you have to change the blitter mode twice on each line of each polygon. You also lose even more cycles since you can't cache part of the blitter setup. Ouch! Of course, you can target the CLUT a different way if you plan to texture at 60FPS, but if that's the plan, rendering to the line buffers is faster -- you save the OP processor overhead that way. I wrote a 60FPS "texture mapper" demo for the Jaguar when I first got my BJL, and it's fine if you only need a couple of polygons and think Doom's horizontal resolution is sharp enough. Oh, yeah, hope you didn't need any time left for an actual game. Anyway, blitting FROM the CLUT isn't the worst idea if you don't mind 16x16 textures, but I think low res textures are kind of pointless. I wouldn't be mind being proven wrong. - KS Interesting results - When I tested in code originally it was a definite win to use the CLUT, but maybe that's the difference between a demo and game code - ( and this was many many years ago ) ( I should turn on the jaguar and try texturemapping again - but I'm having enough trouble just trying to find time to continue working on gamecode , the poor jaguar is gathering a lot of dust )

It's nice that you can blit 16 bit to the CLUT ram though

I don't completely understand the Pi . It is very cheap, but no keyboard/display - and you can get cheap chinese android tablets that have similar cpus ( arm 9/11 ) with screen & wifi for £50 on amazon or ebay - wouldn't a more complete machine be a better base for an educational machine. ( Looking at the cheap wondermedia tablets they actually have a cpu/memory on a daughterboard anyway )

I think I'll have to disagree on that point - Although the jaguar ii chipset was better than the first it would still barely match the PSX or even the Saturn. Bilinear filtering was there but it ran at 1/4 the rate of normal texturing , and there was no perspective correct texturing in hardware. It would have been fun to program though It certainly maintained and extended the flexibility advantages of the original Jaguar, but by "higher cost bracket" I mean building it out into a high-end configuration with no concern for backwards compatibility and with 33 MHz EDO DRAM (assuming the chips were bumped to 33 MHz) and Oberon on a dedicated bus (say 2 MB of 33 MHz 64-bit EDO DRAM) and a separate bus for the CPU (either shared with audio or keeping a separate slow bus for audio as well). Ah - so you're not talking about the Atari Jaguar 2 , but a new imaginary chipset with no design for cost Even with 2x ram b/w though you wouldn't speed up the theoretical performance of the blitter - 4 pixels in 2 cycles is aimed at 64 bit fast page memory. EDO/SD ram would be better used to reduce the component count by only needing 32 bit wide memory. A pretty major reimagining of the Jaguar - why not just fix the h/w bugs, drop the 68k and release a CD only machine in 93

I think I'll have to disagree on that point - Although the jaguar ii chipset was better than the first it would still barely match the PSX or even the Saturn. Bilinear filtering was there but it ran at 1/4 the rate of normal texturing , and there was no perspective correct texturing in hardware. It would have been fun to program though