Prince of Persia

[potatohead]

192 LMS instructions will do the screen, and another set for the other screen. Two display lists required then. Instead of writes to the soft switches on Apple, the Atari just needs the right display list pointed to at the right time.

 

That more or less means the Apple renderer code would work just fine, eliminating a lot of hassles.

[sack-c0s]

doesn't the apple renderer rely on artifacting that wouldn't occur on the A8 though?

 

Or are you thinking of switching the graphics data over but just using the original render code?

[potatohead]

Yes.

 

I've got my Apple and Atari on right now poking around a little, just looking at pixels and colors.

 

The Apple is a black and white computer that has the color signal added so that it artifacts on the NTSC signal. Artifacts are interesting really, well if you have an NTSC display that is. The screen is 6 color, but... patterns really do have a lot of impact. More can be done than one thinks.

 

Atari machines do the same thing in graphics 8, but they lack the attribute bit. Poking in a P/M or two results in the necessary additional colors, with some background coloring that I don't think is too big of a deal. Frankly, I think it might turn out rather cool done that way, but it would also be NTSC only... Emulators would actually look a bit worse than a real TV would. Just turn the color saturation down a little, contrast up and that P/M overlay on a black and white ANTIC F screen kind of just blends in. Side discussion though.

 

In any case, the fact that it's possible to just setup graphics screens and use the Apple renderer as is seems like a quick path. One could get the game running and nicely playable with no art changes at all! From there, it's a skinning contest of sorts. Set it up for both ANTIC F (high res) and ANTIC E (4 color), and let people build the art for it, and or optionally add the P/M overlay on either mode. Seems there are some challenges in there... Maybe some game parameters might need changing to make new art really work, but that's much easier on a running program than not.

 

So yeah, get it to run 4 color, figure out where to stuff P/M code and data, then make art choices from there... Seems odd, but unlike a new title, there is a lot done already.

 

The code posted on github doesn't include the booter for the Apple. Bummer that. Would be kick ass to get it running there first, just so it's a known thing. Suppose somebody could go and scrape that off the game disks too.

 

That is where my thoughts ended up today.

 

Well, that and I've done display list stuff in the past, but never LMS one right after the other like that. Does it work? Are there impacts?

[xxl]

maybe this help - display list for Antic:

mode	 equ $f
antic	 .byte $70,$70,$70
 :192 .byte $40+mode,a(apple_ekr+((#%*$400)+((#%$40)/8)*$80+(#/$40)*$28)
	 .byte $41,a(antic)

 

Apple2 code runs on atari8:

 

[+Stephen]

Well, that and I've done display list stuff in the past, but never LMS one right after the other like that. Does it work? Are there impacts?

You can LMS every scanline, the only downside is you lose a lot of CPU cycles due to ANTIC fetching both address & data every line.

[Xuel]

Apple2 code runs on atari8:

 

Wow! How does that work?!

[potatohead]

Graphics data needs more work... All those attribute bits. There is a fair amount of work dealing with those and art... So much for the quick path.

 

Very nice XXL. Ahh there are some classics in that thread... not games. Cool beans for single load 48K games.

 

Reading through the Apple source some today as well. Holy cow! After reading through some of this, I'm starting to piece together how it works.

 

MrSid, you rule having done it from just the finished binary images.

[sack-c0s]

I'm being an utter bloody idiot and missing a simpler answer, aren't I?

 

If you have 1bpp with artificating like that, can't you just throw the same video data at a 2bpp screenmode, with the 4 colours set up to be representations of what they would artifact to on the Apple?

[Rybags]

Further processing of the graphics data would slow most Apple II games down too much. VBXE could help out somewhat though.

 

A 2bpp mode on Atari won't really help. The msb affects all 4 pixels on Apple but only the leftmost on Atari.

Also I believe the bit pairings decide whether white or a colour is displayed. It's a sorta weird way of doing bitmap but gave the Apple II a cheap way of putting more colour up using less Ram.

[sack-c0s]

ahh - I was thinking it was on a pair-by-pair basis so was roughly like a 2BPP mode.

 

Time to do a bit more reading on this...

[Creature XL]

Is it possible to to convert the Apple gfx data with a program running on the PC (or TB XL ).

"Just" do what the attribute bit does to the 4 pixels in a byte. I have no idea what the attribute bit changes, but I am pretty sure it can not be simulated on a 4 color A8 screen, but I guess it is far better then the vertical stripes (see the emu video posted by XXL).

 

The gfx would not be the best the A8 could do, but the work to have PoP running should be minimal and as mentioned above, could be adjusted later.

 

<formatwar mode>

Would it be awesome to show the C64 guys we can actually run Apple2 code without much work?

</formatwar mode>

Edited February 18, 2013 by Creature XL

[The Usotsuki]

<formatwar mode>

Would it be awesome to show the C64 guys we can actually run Apple2 code without much work?

</formatwar mode>

 

It would certainly be interesting to see as an Appletard

 

And doesn't the 400 have a 1.29 MHz 6502 or something? The 64 has the same clock speed as the Apple. Theoretically your boxen should run Apple ][+ software BETTER than an Apple ][+, once the differences in graphics capabilities are accounted for.

 

...inb4 FPBASIC and DOS 3.3/ProDOS running on an 800 (or more likely an XE). I'd dig that. xD

[potatohead]

The attribute bit shifts the pixels over just a tad so that they artifact different colors.

[sack-c0s]

Wow! How does that work?!

 

if you can flatten the memory out then any given 6502-based machine can run any others code, but then you have the issue of all the hardware writes and screen memory being in the wrong place.

 

You might get lucky on the C64 and be able to configure a similar mode, but in this case that's not going to happen.

 

Because the Atari is so flexible with various linear (well.. at least as far as a single line goes) modes and the fact you can repoint the graphics hardware to any address you want I'm guessing you just locate a block of system shim-layer code somewhere the original machine wouldn't touch (e.g because it's ROM) that sets up a DLI, fakes interrupts, translates keyboard input and writes it out to expected locations, etc. and manages the 'alien' code in a fairly transparent way.

 

I've had commodore 16 stuff up and running on the Atari this way using this kind of technique

[José Pereira]

An old C16 trying of PoP:

 

It is in Mono Hi-Resolution but it's 32Bytes wide screen so maybee taken from the Zx spectrum version.

32 or 40Bytes wide apart and having us just the PMGs to colour something on screen for the PAL land I really don't see anything good would come (only thing I am almost sure is that I would have the 4Missiles as the Fire/Torches as we can have 3maximum, probably 4 on some screens thn 4Missiles for them. The 4PMGs just for the guys and aren't enough, I think... then all screen gfxs in Mono).

Even the guy behind C16 hadn't best colour choice I still don't see it any better in any other colour.

 

 

And Apple2 at 40bytes wide it's the original code and can be copied/port directly and more: it's simple because Pillars are in chars and this C16, that seems ZX version isn't.

 

 

P.s.- Taken the Apple2 7-bit bitmaps -> 8bit of A8 just need someone to get me a picture of all the chars/tiles. In a day I'll get them.

Edited February 18, 2013 by José Pereira

[potatohead]

The art needs a touch to render cleanly in Antic E. It would render reasonably in ANTIC F, if the intensity bits are all set to 0. In my reading, there are some places were colors are chosen, and those would have to get touched too to prevent that bit from getting set. All of that just to make things visible and playable. In ANTIC F, there would just be gaps showing up as vertical stripes. No big deal for running it.

 

I played with the color last night just to verify some things. Since I live in NTSC land, rarely seeing PAL devices, I've exploited this quite a lot over the years, inspired by the Apple, which is just a monochrome computer with the color signal turned on.

 

Any single pixel will show as a color pixel. If it's even, that's one color, if it's odd, that's another color. Two of them together basically show as white or black, and that's because the smaller pixel size contains frequency components that a TV will see as color info, due to the 3.58Mhz colorburst separating intensity data from color data on the composite signal. Because there are 7 bits per byte on the Apple, some shuffling of the art needs to happen for Antic E displays to get colors to line up with artifacts.

 

The Apple display is actually clocked at twice the pixel clock. This is where double high resolution comes from on later models, BTW. Just imagine GR 8, with some option to shift the pixels over just a tad, and that's what the Apple does for the byte that has it's high bit set.

[José Pereira]

Anyone with a real NTSC Machine can load load this Hi-Resolution black and White and post here what he get on A8 using the Artifacting?

(This version is different from the video as it's in Black and White and it's 40Bytes wide screen)

 

If, for NTSC people and using Apple2 code then this gfxs wouldn't be good looking. But they still have to be changed to get some colours of the A8 NTSC Artifacting...

 

 

 

 

 

By the way:

1.)- On AtariWinPlus Emulator we have CTIA and GTIA the two chips. O.K. and what's that Brown/Blue two other artifacting. It's just Emuçlator or there are Machines that display that colour?

2.)- On this Emulator we have the traditional two colour artifacts, like, for example, Pink ang Green (like a middle light luminance) but in some bits it can also display these two in light luminance (same for the Blue and Brown,...) Is this also on real Machines?

3.)- Can we say that AtariWinPlus Artifacting display like almost 'the real thing'?

4.) This Emulator gets solid looking Artifacting while Altirra they seems so bad, why? Is it ALTIRRA bad or are the Artifacts at ALIRRA showing the bad looking on an old days/old T.Vs display?

[potatohead]

Jose' I would ignore old CTIA, etc... Yes, they do display other colors.

 

The NTSC artifacting is simple: Even pixels are one color, odd pixels are another color. A single pixel will be colored, it does not take two of them for color to appear on screen. This is probably the biggest difference from standard 4 color screens, which require both bits to produce color. A single pixel, even or odd position on screen results in a tiny colored pixel. You can see this in the Apple screen shots in the many patterns as well as the nice blue on black brick work seen between pillars, etc...

 

Two together does not artifact much and they will be seen as either the foreground or background color, depending on what somebody has set the Atari to do. If that's black and white, then two together will be black or white.

 

Imagine an Antic E pixel that could be divided into two pieces, yet still be colored. That is what single pixels on an Apple do. So the other combinations work out just like 4 color screens do. 1010 = odd color 0101 = even color. You will notice that colors can't be precisely aligned this way. Repeating patterns make colored regions.

 

IMHO, the emulators that just post up 4 colors for artifact graphics are idealized and not entirely representative of what a real TV would show. However, they do basically render artifacts useful and playable, etc... Works for me.

[José Pereira]

Now sowething came to my mind:

If two consecutive pixels we don't get artifacting but if based on A8 2:1 colour clock the two consecutive hi-res pixels are in two colour clocks, one in each?

I think that emulators gives artifacting but can only confirm when I get home.

This way we have two consecutive but the odd and even are in different colour clocks. So what's the truth here?

[potatohead]

One "color clock" = one ANTIC E pixel = one P/M pixel.

 

One ANTIC F pixel = 1/2 "color clock" = 1/2 P/M pixel.

 

One Apple pixel = one ANTIC F pixel.

 

Artifacts appear at pixel sizes smaller than ANTIC E.

 

Two consecutive ANTIC F pixels will display as non-artifact, whatever colors are set on ATARI. Two Apple pixels will display as either black or white. Apple is a monochrome computer, the only color it has is artifact color.

 

A single ANTIC F Pixel will display as a colored pixel on NTSC, one color for even pixel, a different and generally complimentary color for an odd pixel.

 

A single APPLE pixel will display as a colored pixel, one color even, different color and generally complimentary odd.

 

00 = black

01 = one color

10 = the other color

11 = white

 

On APPLE, the high bit in each screen memory byte does not display on screen, instead it shifts all the pixels in that byte (7 of them) just a small amount so that two more complimentary artifact colors are seen.

 

On BOTH, if you want a color region, you simply treat the display like a 4 color display.

 

Black region = 0000

One color = 1010

Other color = 0101

White = 1111

 

No matter what, if there are two or more pixels together, the image is black or white on APPLE and the foreground / background on ATARI. However, patterns do show color in the inverse too.

 

1011111 = White with the "even color" appearing as a darker colored pixel. (wierd, but you can see this in the PoP art on pillars a lot)

1101111 = White with the "odd color" appearing as a darker colored pixel.

 

If the high bit were to be set, it's the same effect, but with the other two colors happening for that byte. BTW, both computers do this. The difference simply is the APPLE has two other artifact colors in bytes that have the high bit set.

 

I think that means converting the art to ATARI Artifact colors (4 color) and then using the sprites to overlay entire bytes that have the high bit set on APPLE to get other colors.

[Tempus]

One idea. The A8 is faster than an Apple II. May be as a first approach the Apple screen memory could be converted to A8 GR#15 in real time. The Apple has a hires of 280 pixels, which could be mapped to 140 pixels in GR#15. Perhaps there would no need for converting all the graphical objects to A8.

[potatohead]

This game requires 124K RAM for it's run-time foot print on the Apple. From what I can tell so far, Mr Sid used a cart, which works great compared to touching a disk, which is what Jordan had way back when. He got it to 64K, and I think being able to quick swap things in and out got it done. 64K RAM machine is tight though. Had a cart been possible on the Apple, who knows? Prolly 64K because of how Mr Sid got it all sorted.

 

Adding buffers probably doesn't make sense.

 

 

And the A8 is faster, but maybe not that much faster when it all adds up. Apple has no screen DMA, making it quicker than a C64, slower than an A8. A long time ago, I had written a short program to simply display numbers on the screen. 0 to 9 million or something like that. The Apple was within 30 percent and it varied some depending on what the Atari was doing for display, running it's graphics DMA, DLI, etc... If the display gets busy, the two machines could end up on par or more likely very close in draw speed doing software sprites. I'm sure that varies by task, but it's not a factor of two or anything like that. Lots of art, lots of bit masking and drawing going on too.

 

I'll have to run those tests again someday.

 

Heck, I won't say it can't work, but I would be dubious. This title wants a nice slice of CPU for rendering, and it needs lots of buffer space.

[potatohead]

There is one other subtle thing about artifacting:

 

Color graphics operate at 1/2 the total screen horizontal resolution. Two pixel steps basically. However, solid objects, where two or more pixels are stacked together, can move with single pixel steps.

 

Just an FYI that I do not think matters for this title. And Atari ANTIC F does the same thing, just without the Apple attribute bit issue.

[MEtalGuy66]

The Apple version is using double hi-res color, which means that the actual monochrome (shown without color artifaction) image is going to be 560x192.

 

That pacman crap you were messing with earlier is just standard hi-res.. WHich means it's actual monochrome resolution is 280x192.. Prince of Persia does not run in this screen mode.

 

Prince of Persia takes full advantage of the double hi-res features available with enhanced (128k) Apple II.. It stores half of the 560x192 bitmap in base ram, and the other half in "auxilary" ram on the 80 column card.

 

After about 1984, all apples came with this capability from the factory, which is why the games industry was fairly quick to adopt it's use for getting many more colors (16 instead of 6) on high resolution graphics screens..

 

With Double-Hi-res color, the "artifacting" produces 1/4 the actual horizontal monochrome screen resolution.. There are 4 mono pixels for each perceived colored (artifacted color, that is) pixel.. And actually, it's a bit more complicated than that.. You may want to go read about apple double-hi-res color before you decide on a strategy to convert the apple II bitmap data for use on the atari.

Edited February 19, 2013 by MEtalGuy66

[potatohead]

only for title screens and credits --the game runs in normal high res, double buffered