Crazyace

That link also mentions something about a lynx 64 (an updated lynx perhaps or a jaguar with lynx compatibility) Hi Carmel, I think that page is a 'spoof' - It speaks about the Jaguar 2 already being launched, and Sony withdrawing from the console business

It would have been more competitive, but not enough to spank the PS1 ( even with difficulty ) Also , we have the technical reference manual for Midsummer - and it's nowhere near as good as the specifications you've quoted. The reality is a lot more mundane, a step up from Jaguar, fixing bugs, improving sound and adding the Risc CPU - maybe more like the 3D0 performance for texturing.

I was initialy thinking about the most important thing missing from the original ST - and scrolling wins hands down. But a 256 colour mode ( either 16 pallette + 1:2:1 low RGB bits , or just 332 RGB direct ) at 160 pixels as an additional mode would be great. I find blitting less important - I'd much prefer a slightly faster CPU. VGA might only be important for the 'new' STe - In 89 VGA would be out - so moving to a 64 bit memory bus would give 320x480x256 and 640x480x16, and a 16MHz 68000 would give 2x the cpu speed with a minimum of compatibility issues.

I seem to remember both Mac and PC only having floppies at launch - at least the ST had the interface there at the start I agree with Thorsten that the STe was too little. It should have been more like a combination of the Mega STe and TT - 8/16MHz switchable 68k for maximum compatibility, along with 256 colour / VGA graphics. Scrolling wasn't enough - it should have been in the ST, not left almost 5 years...

ST's supported harddrives from day 1

In that case....what was the point in the STe....Apart from being an 'amiga-ised' ST...if you remember the interviews contained within the review ST format gave when the STe was launched the programmers like Bak, smithson et al, weren't exactly heaping wholesome praise on the system (i guess though, they stopped short of slagging the machine off) The STe was just too late , after all you still had to support the normal ST in your titles. Scrolling hardware support should have been in from day 1 , by the time the STe came out the Amiga was way ahead.

Never saw Super Stario land before - It's pretty cool - seems to need 1MB though - I wonder if everything is drawn as 'sprites' against a blank screen

Anarchy is pretty nice - much more fullscreen, but it's not really a full background - more a repeating pattern that fills the screen. It's an excellent technical feat though. You are missing the point though Carmel - with hardware scrolling there would be almost no CPU cost involved in scrolling, leaving more time for other things such as sprites or particles. (Edit spelling mistake on name)

Goldrunner and Return to Genesis are both well programmed games - but they prove my point. Neither is full screen, and Goldrunner's background is only 4 colour. Return to Genesis scrolling area is 288x96 - less than half the screen area, but the parallax is excellent. ( There's some info about RTG here: ftp://ftp.worldofspectrum.org/pub/sinclair/magazines/TheGamesMachine/Issue06/Pages/TheGamesMachine0600063.jpg )

Scrolling, simple hardware acceleration (line copy, fill, etc) short of a full blitter would have been nice, but how much would chunky/packed pixels have sped up software rendering? (let alone double the CPU speed) And for non-game applications, do you think that a 256 color display mode could be more significant than added hardware acceleration. (especially if that meant 8-bit chunky pixels speeding up software blits and focusing on faster CPU speeds) Especially after the fact (without hardware acceleration initially) boosting CPU speed would mean all (non timing sensitive) older programs would be faster as well. Not to mention 3D stuff or software scaling and in the context of porting PC games you'd be dealing with software renderer engines as well, and with VGA games especially you'd have 8-bit chunky pixel frambuffers being focused on. (the Amiga version of Wing commander was pretty limited, but imagine a port to a 16 MHz 68k system with a 320x200 8bpp linear framebuffer -did the Amiga port even use the blitter?) Of course if they were competing with VGA, that did had hardware scrolling as well, but I'd think in many cases the 8bpp chunky framebuffer and 256 indexed colors (at least 12-bit RGB) would be generally more significant. (again, especially looking at non-game applications as well) If they didn't bump to 12-bit RGB they might as well do away with indexing and go to plain 8-bit direct RGB (maybe a toggle for 3-3-2/3-2-3/2-3-3). Scrolling is the most important one - as it free's up a massive amount of CPU time in scrolling games. Without it the ST was hamstrung when trying to replicate common 8 bit games. Other stuff ( blit/256 colours ) would require a lot more silicon. ( Imagine a 10MHz cpu at launch though , that would have been nice ) Didn't VGA ( or MCGA ) come out in 1987? 16 colours was a good choice - ( Amiga was better, but it was a much better design )

As far as I'm concerned the only mistake or bad decision was not including scrolling in the ST design. ( Having a packed pixel mode rather than bitplanes like the Apple 2GS would have been nice as well ) No scrolling meant that the CPU had to waste a lot of time moving the background - in many cases a 50fps game on the Amiga would be at least twice as slow on an ST - as almost one frame of time would be needed to repaint the background to simulate the scroll.

Hi Dave, I use this to get 6 different coloured graphic shapes ( all the same character ) for a puzzle game style kernel ( Players set 3 copies narrow as P0 P1 P0 P1 P0 P1 ) ;Single line of graphics ldx #10 line stx index inx ldy colour stx COLUPF lda graphic-2,x sta GRP0 sta GRP1 ldx colour+5 txs sty COLUP0 ldy colour+1 sty COLUP1 ldx colour+3 ldy colour+4 lda #$f2 sta COLUBK lda colour+2 sta COLUP0 stx COLUP1 sty COLUP0 tsx stx COLUP1 lda #0 sta COLUBK ldx index dex bne line

That's a shame. It would have been nice to see your latest creation

Seems, that somebody is working on it: Great! That's a really nice looking version - I love the way the runnig animation has come out ( and the parralax of course )

The A8 does have a very fast CPU. A Z80 really should be clock 4x to make the memory accesses the same as a 6502 , 2x clock really isn't quite enough.

Memcpy would be LDI for Z80 , 16 cycles vs lda src,x sta dest,x inx 10 cycles for 6502 ( 8 cycles in the best case where you unroll and dont need the inx every time. So the 6502 is at best equal to the Z80 ( assuming the 2x clock ). ( Regarding Antic - well that's not a z80 v 6502 comparision - Antic is way better than the video h/w on the Spectrum , in my opinion of course )

Definitely no interupts - but it's worth it for the speed up. ( The 6502 stack instructions are byte only to page 1, which is the real limit )

I think with a 4 to 1 clock ratio the z80 would always beat the 6502. With a 2 to 1 ratio ( Coleco to A8 ) the 6502 wins. I really prefer the 6502 addressing modes though.

The pop de is a wonderfull z80 hack. pop's are 16 bit loads with address updates - and on the z80 the sp is 16 bits so it can point anywhere. So the optimisation is to retarget the stack as a index pointer. It's an evil hack, which is why I used self modifying zp 6502 code to compare against it.

That'll be YouTube, i've played it quite a bit and it's smoother than character steps. There's a couple of other games using the same techniques but they're not shoot 'em ups so i can't remember names for the life of me! =-) You're right - I just downloaded it, and it runs smoothly ( under BlueMSX ) - looks like the same technique used for Moon Patrol on the Colecovision. It's very nicely put together

Seleniak isn't really that complex though, more charset redefinition than actual scroll. doesn't look like it's fine scrolling - still character block movement. It's the one limitation of the TI chip ( hurting the TI99 , Colecovision, and MSX ) that really hurts when compared to the A8 ( or C64 )

Not too many 16-bit registers so the memory 16-bit add would be more common. 16: ld hl,(203) 10: ld de,number 11: add hl,de 16: ld (203),hl 53 cycles on Z80 vs 22 cycles for your 6502 code. The trick on Z80 is to keep things in registers as much as possible. For example if you were summing an array of 16 bit numbers: 7: ld c,(hl) 4: inc l 7: ld b,(hl) 6: inc hl 4: ex de,hl 11: add hl,bc 4: ex de,hl against (assuming no page crossing) 2: clc 5: lda (ptr),y 3: adc zpacc 3: sta zpacc 2: iny 5: lda (ptr),y 3: adc zpacc+1 3: sta zpacc+1 2: iny Giving 43 cycles Z80 against 28 cycles 6502. Best optimised cases Z80. 10: pop de 11: add hl,de 6502 ( Code in zp ) 2: clc 4: lda data,y 2: iny 2: adc #acclow 3: sta *-2 ( Change imm acclow ) 4: lda data,y 2: iny 2: adc #acchigh 3: sta *-2 ( Change imm acchigh ) 21 cycles Z80 against 24 cycles 6502 in this case - a very rare result

The z80 is clocked higher as standard, probably as it doesn't use 2 different clock signals ( For example in the MSX machines it's 3.58MHz which is 2x the Atari clock ) A 16 bit add is just ADD HL,DE at 11 cycles. Actually for real comparisions a 'memory cycle' on z80 is 4 cycles compared to 1 cycle on the 6502 - so clock/4 could be used to compare timings.

Ah - for an exact Yoomp style remap I guess it would have to be this: 10: pop hl 11: add hl,de 7: ld a,(hl) 10: pop hl 11: add hl,de 7: or (hl) 10: pop hl 11: add hl,de 7: or (hl) 10: pop hl 11: add hl,de 7: or (hl) 7: ld (bc),a 119 cycles - That's way too slow. As I said the indexing sucks on z80 for this type of access.

A more common comparision might be the 'bitmap' sprite routine. 6502. - 21 cycles 5: lda (scr),y 5: and (mask),y 5: ora (data),y 6: sta (scr),y or maybe optimised/unrolled.. 17 cycles 4: lda scrline,x 4: and mask,y 4: ora data,y 5: sta scrline,x z80. - 32 cycles 7: ld a,(hl) 10: pop de 4: and d 4: or e 7: ld (hl),a Given a 2->1 clock the advantage goes to the z80 here. When comparing specific machines like Spectrum / C64 the clock difference was far great than 2x though - for the A8 it's closer ( if you don't steal too many cycles away with Antic )