5-color mode with almost no restrictions

[fox]

I have an idea for a new graphics mode: 160x240x5 colors.

Normally, in ANTIC 4 / GRAPHICS 12 the selection of COLPF2 vs COLPF3 is in 4x8 cells.

My proposal is to have 2x1 cells.

 

How to do that:

 

First step is having 1 line high cells. This can be done by writing to VSCROL to trick ANTIC to fetch new characters every scanline. This is the easy part.

 

Second step is to double the DMA rate. In the badline of ANTIC 4 the DMA already uses all the cycles in the visible area, alternating between character and font fetch. Using HSCROL, we want to trick the DMA machinery to fetch both characters and font every cycle. Fetching a character every cycle will double the resolution of the 5th color. This will be very tricky, as ANTIC will put both the screen address and font address on the address bus. Using CHACTL to mirror the characters vertically will be probably needed to not have the low-order address lines cleared.

[emkay]

Following your idea, it has to be possible to change every char 2 times in the screen memory and free from the arrangement of the other chars in a line. What in the Atari could do this that fast?

[fox]

I think you didn't understand my idea. I want ANTIC to fetch 80 characters per line.

[phaeron]

The name and character data fetches will indeed collide. Haven't tested this in the display area, but in the horizontal blank area with special DMA you get the bitwise AND of the addresses involved. That'll probably require trying to keep the character data address near the end of a page at all times (as many 1 bits as possible).

 

The address computation also has a delay since it is built for 1 fetch / 2 cycles as the fastest speed. IIRC, you get funky addressing in the line buffer when running 1 fetch/cycle; don't remember if this also applies to the direct fetch from memory on the badline.

 

Shift data may be a problem. The playfield shift register already runs at maximum speed in ANTIC 4 so doubling the fetch rate won't speed up the shifter; this means that it will only get a chance to shift out four bits before it is reloaded again. Tests I did years ago suggested that when this happens the new byte is merged into the shift register similarly to when players are reloaded. Since the playfield shifts out bits MSB first, this will cause bit 7 from the name to merge with the character data. I don't remember offhand if the effective result is an AND or an OR.

 

CPU time is going to be very short as setting this up requires allowing ANTIC to fetch on every other cycle across horizontal blank and horizontal scrollijng will enlarge the fetch window. Quick estimation suggests as low as single digit cycles per scanline.

[emkay]

I think you didn't understand my idea. I want ANTIC to fetch 80 characters per line.

Not sure , if i understood it wrong ....

You'd have to reach to produce a character "fetch" in half of the "fetching" time of a normal mode. In theory this means to double the system clock...

[NRV]

Nice.. so when do we expect a working test? x)

 

Also, why 240 lines? .. I suppose it should work for any number of lines?

And how would using narrow mode (128 pixels) help you to achieve this?

Is possible to still use pm's?

 

Regards.

[fox]

The address computation also has a delay since it is built for 1 fetch / 2 cycles as the fastest speed. IIRC, you get funky addressing in the line buffer when running 1 fetch/cycle; don't remember if this also applies to the direct fetch from memory on the badline.

Didn't know about that. Any details?

 

Since the playfield shifts out bits MSB first, this will cause bit 7 from the name to merge with the character data.

Since we fetch the very same byte to name and playfield, this restricts playfield bit 7. Playfield merging could actually help here.

 

This is going to be even harder than I thought. If we cannot workaround the problem of bit 7, it could turn out not really useful.

[fox]

Also, why 240 lines? .. I suppose it should work for any number of lines?

Yes, any number of lines is possible.

 

And how would using narrow mode (128 pixels) help you to achieve this?

Narrow mode would give more time for the 6502. This mode is very intensive on DMA. Also, the memory refresh would be reduced to 1/9 - what will be the effect?

 

Is possible to still use pm's?

Yes, but PMG DMA will get tricky.

[emkay]

Wouldn't it be more useful to create a tool that allows full PMg multiplexing in hires than to think about something impossible?

[fox]

ANTIC's internal memory is written in badline, but is it read as well?

If so, we have two more problems:

- ANTIC will try to write and read the internal memory at the same time?

- there are only 48 bytes, what when it overflows?

[emkay]

ANTIC's internal memory is written in badline, but is it read as well?

CPU is writing, ANTIC is reading it.

 

If so, we have two more problems:

- ANTIC will try to write and read the internal memory at the same time?

 

ANTIC never writes something, it only controls reads and causes special writes to the CPU.

 

 

- there are only 48 bytes, what when it overflows?

 

nothing will happen.

 

 

Please explain to me, what caused your idea for this.

Edited October 22, 2017 by emkay

[phaeron]

Didn't know about that. Any details?

 

Line buffer addressing is delayed by one cycle, so when ANTIC is running at 1 fetch/cycle it tends to use the address for the next fetch when reading from the line buffer. Only the reads are affected; writes are fine, and the data in the line buffer is OK if you replay it at normal speeds (2f/c or slower).

 

ANTIC's internal memory is written in badline, but is it read as well?

If so, we have two more problems:

- ANTIC will try to write and read the internal memory at the same time?

- there are only 48 bytes, what when it overflows?

 

I think there is only one internal playfield data bus and the RAM operates in pass-through write mode on badlines, so there shouldn't be a problem with running over the line buffer limit -- some writes won't occur but the data will still flow through to the shifter.

 

The internal line buffer address counts over 63 addresses, of which only 48 exist. The other 15 go nowhere -- writes are ignored, reads get blank data. After 63 it repeats.

[popmilo]

... Using HSCROL, we want to trick the DMA machinery to fetch both characters and font every cycle.

Sounds cool... Any documentation that explains how this can happen ?

What is the logic between Hscrol and fetching process ?

[fox]

See ANTIC schematics and Altirra Hardware Reference Manual.

[emkay]

I still don't get it. Even IF somehow the DMA of ANTIC can be shattered to do that "every cycle fetching" (which is simply not possible as the TV signal is a direct projection) , you won't get any benefit there. 5 colors, but no additional "kernel" for extra colors?

[flashjazzcat]

We know you don't get it, but abusing the hardware like this is fun and interesting to read about.

[Rybags]

I've already done something a little bit like described.

 

- Use VScrol trick to produce Antic 4 that is only 2 scanlines high.

- Use Chact for upside-down characters which allows use of 4 of the 8 scanlines for each character to reduce memory waste.

- Use PM underlay to allow an extra colour.

- Use alternating scanlines of colour and luma only in 160 pixel mode to allow 36 colours using PAL blending with restrictions.

 

This was used in a NYD music clip that I did, probably around 2011ish.

 

As for using HSCROL to produce extra character fetches and "better" fidelity. Can't be done, the badline in 40 character modes takes almost all the cycles available.

The other problem, you'd need to replicate the behaviour on the non-badline.

And finally, you'd get little real benefit even if it could be done. Possibly a few narrower characters which might allow changing the optional PF2/PF3 colour more often in those places. I also get the feeling that changing HScrol in such a way wouldn't produce expected behaviours, you'd probably end up with blank spots and some characters being fetched twice.

[foft]

This is an interesting experiment, following! A potential use of the DMA clock bugs.

 

@Rybags, do you have a link or name for the music clip demo mentioned above please?

Edited October 24, 2017 by foft

[Rybags]

I had a look around Atarimania and Fandals, don't seem to be there, and not on my local drive. Probably sitting on an external somewhere.

 

There's NYD threads here since probably 2008 so it should be on one of the compilations. I'm fairly sure it was 2010 or 2011.

[+JAC!]

This was used in a NYD music clip that I did, probably around 2011ish.

 

 

The first thing that comes to my mind is this from NYD 2010. Mode F & 4.

http://www.ppsberlin.de/ppsberlin/downloads/new-years-disc/file/3-nyd-2010

 

[emkay]

We know you don't get it, but abusing the hardware like this is fun and interesting to read about.

If I'm searching for a comedian , I'll send you a PM.

[flashjazzcat]

No humour intended, I assure you. Let's not have noise in an interesting thread.

[emkay]

No humour intended, I assure you. Let's not have noise in an interesting thread.

Dear Mr. Noise!

 

So read post 17 and find the exit ,don't forget your fans , and next time, post into a thread where you have something to say.

 

Thanks.

[Synthpopalooza]

The first thing that comes to my mind is this from NYD 2010. Mode F & 4.

http://www.ppsberlin.de/ppsberlin/downloads/new-years-disc/file/3-nyd-2010

 

NY2010.png

 

That is actually ANTIC 4 with the GTIA alternating with mode 11 and some HSCROL trickery to reduce the area needed for PF2/PF3 conflicts, if I remember rightly.

 

I think Rybags also used the PMGs here as he described above ... This basically gets 96 colors (roughly 14 chroma x about 6 lumas though they aren't all freely usable)

Edited October 25, 2017 by Synthpopalooza

[kenjennings]

Erp... has someone figured out 80 column text output? (This is giving me a Centron flashback.)