mrbombermillzys TT display enhancements

Blogs & guides and tales of woo by forum members.
User avatar
mrbombermillzy
Posts: 1441
Joined: Sun Jun 03, 2018 7:37 pm

mrbombermillzys TT display enhancements

Post by mrbombermillzy »

Ok, so I guess I should start a blog here, as despite just hanging around cracking jokes and whatnot, I do have some (hopefully) cool stuff on the horizon.

SO currently, having had 2 baby boys in close succession, both my spare time and brain cell capacity to innovate has taken its toll (hence the said lurking to mainly comment on @Cosmic Puppet threads.

However, I do have a few things in the pipeline which may interest the casual reader:

Firstly, before the child situation got too involving, I was working on a high colour Atari TT colour display system which would be able to display the full 4096 colour palette on screen.

Preliminary testing of just the basic raw palette write throughput eventually produced images that could change up to ~64 palette indexes per line. This could be flexibly displayed by either a single line width of 64 x pixels width and the full 480 y axis pixels/lines, or up to 256 x pixels but with a 4x raster 'line' size(i.e. 120 different y lines). Or an inbetween size of these .See the examples below:


P1030646.JPG
P1030646.JPG (124.93 KiB) Viewed 3344 times
P1030640.JPG
P1030640.JPG (113.76 KiB) Viewed 3344 times
P1030645.JPG
P1030645.JPG (130.27 KiB) Viewed 3344 times

Skimming over the technical details completely :lol: I guess with some judicial use of the palette placement, these methods could be used for some nice kaleidoscopic demo effects or smaller screen images.

Infact, without the needed cleaning up/resizing/blanking the border and displaying this image properly, I have already achieved the goal of displaying an image in the full 4096 colour palette on a TT! :D

But moving forward, I have looked further into a more efficient display system and have literally gone down the rabbit hole, with endless possibilities presenting themselves theoretically (until such a time as I try to code the assembly test, only to find either a fatal flaw in my logic, or lack of raw speed to follow through with).

Coming through the other side, having explored many angles and method types and I believe I can display a 320x480 image in full 12bpp without having to reduce any colours on most normal images (well the ones I have been testing anyway!)

I MAY also have found a way to display moving sprites on a background with a high colour count, but dont get too excited, as it is a long way from working yet. (Its past the theory, into the practical testing phase).

Anyhow, Im sure thats more than enough for a first post. More details when I get some time to work on it.

Im hoping starting a blog here will motivate me to try to find some time to continue the work. Dont hold your breath though! ;)
User avatar
Cyprian
Posts: 387
Joined: Fri Dec 22, 2017 9:16 am
Location: Poland

Re: mrbombermillzys TT display enhancements

Post by Cyprian »

sounds cool
Lynx I / Mega ST 1 / 7800 / Portfolio / Lynx II / Jaguar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
DDD HDD / AT Speed C16 / TF536 / SDrive / PAK68/3 / Lynx Multi Card / LDW Super 2000 / XCA12 / SkunkBoard / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
http://260ste.atari.org
User avatar
mrbombermillzy
Posts: 1441
Joined: Sun Jun 03, 2018 7:37 pm

Re: mrbombermillzys TT display enhancements

Post by mrbombermillzy »

Hey thanks Cyprian :D

Yeah, its getting there, but its a hell of a lot of work.

I dont just start randomly coding the end product. Instead I have to code shifter/interrupt/CPU cycle test suites and colour information tools, etc just so that I can take the correct course of action before I can even start to try out the end results... hence the long delay.

(The TT does not have either the demoscene codebase/knowledge of the ST line, or a particularly accurate explanation of the video subsystem, hence the slower progress; that and my less than dependable cycle counting of the 030 over the 68000).
Steve
Posts: 2570
Joined: Fri Sep 15, 2017 11:49 am

Re: mrbombermillzys TT display enhancements

Post by Steve »

Very cool :) I have a TT so looking forward to playing with the stuff you come up with.

By the way a little off topic & into the hardware realm rather than software, but you know how an OSSC can be used to 'fix' the TT's slightly odd VGA timings to get a pixel perfect output? (I have links and details if you don't know what I'm taking about) I was wondering if it may be possible to create a smaller, TT specific VGA filtering device that solely exists for this purpose, if you know what I mean. What do you guys think.
User avatar
Cyprian
Posts: 387
Joined: Fri Dec 22, 2017 9:16 am
Location: Poland

Re: mrbombermillzys TT display enhancements

Post by Cyprian »

Steve wrote: Fri Feb 12, 2021 10:54 pm By the way a little off topic & into the hardware realm rather than software, but you know how an OSSC can be used to 'fix' the TT's slightly odd VGA timings to get a pixel perfect output? (I have links and details if you don't know what I'm taking about) I was wondering if it may be possible to create a smaller, TT specific VGA filtering device that solely exists for this purpose, if you know what I mean. What do you guys think.
The main issue is that PixelClock for VGA is 25MHz and the TT uses 32MHz and 16MHz for color modes. It means that the TT has 33% more pixels per line than VGA specification defines.

Should be possible to fix that with a new Vertical and Horizontal synchronization (e.g. shorten gap between horizontal sync pulses) but I'm not sure whether the TT allows external synchronization like the ST Glue.

Theoretically the TT supports external sync.
https://github.com/Number0000009/atari- ... isting.txt

Code: Select all

-------+-----+-----------------------------------------------------+----------
$FF820A|byte |Video synchronization mode                    BIT 1 0|R/W
       |     |0 - 60hz, 1 - 50hz -------------------------------+ ||
       |     |0 - internal, 1 - external sync ------------------' ||      (TT)
mrbombermillzy wrote: Fri Feb 12, 2021 9:35 pm I dont just start randomly coding the end product. Instead I have to code shifter/interrupt/CPU cycle test suites and colour information tools, etc just so that I can take the correct course of action before I can even start to try out the end results... hence the long delay.

(The TT does not have either the demoscene codebase/knowledge of the ST line, or a particularly accurate explanation of the video subsystem, hence the slower progress; that and my less than dependable cycle counting of the 030 over the 68000).
From technical point of view the TT Shifter is almost the same the ST's one. Just more color registers, 4x wider data path.
I've done a Spectrum512 like test for TT and it worked fine. Sync with the beam and changing palette works in the same manner like on the ST
Lynx I / Mega ST 1 / 7800 / Portfolio / Lynx II / Jaguar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
DDD HDD / AT Speed C16 / TF536 / SDrive / PAK68/3 / Lynx Multi Card / LDW Super 2000 / XCA12 / SkunkBoard / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
http://260ste.atari.org
User avatar
mrbombermillzy
Posts: 1441
Joined: Sun Jun 03, 2018 7:37 pm

Re: mrbombermillzys TT display enhancements

Post by mrbombermillzy »

@Steve Yeah, as Cyprian says. Also, I think the TT came out just as the proposed VGA standard changed (IIRC), hence the wrong timings/oversize borders.

I dont know what you mean with the scan converter, so link away! I would be interested to see.

@Cyprian

I know in theory its similar, and yes, Im syncing on the above pictures too. But its nowhere near being nailed/fully documented like the STe. (Think Troeds lecture about the ST hardware). Still having to find out stuff on my own with no prior ST system coding knowledge and I havent been at it for that long really.

As for the external sync: as far as I know for the external sync, that bit is there for ST compatability (although inverted). There is no external sync line in (like on the STe monitor pin) on the TT as the Video port is standard VGA HD15 pinout. Therefore, no sync input.

What would be terrific would be if one of the HW guys here made a HW TT overscan circuit.
User avatar
Cyprian
Posts: 387
Joined: Fri Dec 22, 2017 9:16 am
Location: Poland

Re: mrbombermillzys TT display enhancements

Post by Cyprian »

mrbombermillzy wrote: Sat Feb 13, 2021 12:14 am @Steve Yeah, as Cyprian says. Also, I think the TT came out just as the proposed VGA standard changed (IIRC), hence the wrong timings/oversize borders.
The TT design is that (exactly as in the ST) TT Shifter works synchronously with the motherboard/CPU. Changing the PixelClock to VGA's compliant 25MHz, would make the same change also for the mobo/ CPU (what we wouldn't like). Therefore I suspect they did it on purpose.
mrbombermillzy wrote: Sat Feb 13, 2021 12:14 am @Cyprian

I know in theory its similar, and yes, Im syncing on the above pictures too. But its nowhere near being nailed/fully documented like the STe. (Think Troeds lecture about the ST hardware). Still having to find out stuff on my own with no prior ST system coding knowledge and I havent been at it for that long really.

As for the external sync: as far as I know for the external sync, that bit is there for ST compatability (although inverted). There is no external sync line in (like on the STe monitor pin) on the TT as the Video port is standard VGA HD15 pinout. Therefore, no sync input.
There are two different external sync in the ST/STE:
- All ST models - external/internal VSYNC/HSYNC;
- STE only - external/internal PixelClock.

And it seems TT has external/internal VSYNC/HSYNC switch. If that's true, would be possible to feed it with better suitable for VGA V/H sync.
mrbombermillzy wrote: Sat Feb 13, 2021 12:14 am What would be terrific would be if one of the HW guys here made a HW TT overscan circuit.
Actually TT Overscan looks pretty simple, besides VME part, which that was used only for switching it ON/OFF. That could be done with external switcher.
TT_Overscan.png
TT_Overscan.png (66.76 KiB) Viewed 3272 times
Lynx I / Mega ST 1 / 7800 / Portfolio / Lynx II / Jaguar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
DDD HDD / AT Speed C16 / TF536 / SDrive / PAK68/3 / Lynx Multi Card / LDW Super 2000 / XCA12 / SkunkBoard / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
http://260ste.atari.org
Steve
Posts: 2570
Joined: Fri Sep 15, 2017 11:49 am

Re: mrbombermillzys TT display enhancements

Post by Steve »

@mrbombermillzy This is the quality you can expect from OSSC and TT:
https://www.atari-forum.com/viewtopic.p ... 6&start=25

Code: Select all

Sampling opt>
640x480 Adv Timing>
H.samplerate: 1023
H.backporch: 128
V.backporch: 29

Allow upsample2x: on

Output opt>
480p/576p proc>
Line 2x
tt_with_ossc.jpg
tt_with_ossc.jpg (319.07 KiB) Viewed 3254 times
User avatar
stephen_usher
Posts: 5580
Joined: Mon Nov 13, 2017 7:19 pm
Location: Oxford, UK.
Contact:

Re: mrbombermillzys TT display enhancements

Post by stephen_usher »

I can get better than that on the OSSC, with correct aspect ratio.

After I've fixed my bike indicators I can clear my table and get the info.
Intro retro computers since before they were retro...
ZX81->Spectrum->Memotech MTX->Sinclair QL->520STM->BBC Micro->TT030->PCs & Sun Workstations.
Added code to the MiNT kernel (still there the last time I checked) + put together MiNTOS.
Collection now with added Macs, Amigas, Suns and Acorns.
Steve
Posts: 2570
Joined: Fri Sep 15, 2017 11:49 am

Re: mrbombermillzys TT display enhancements

Post by Steve »

stephen_usher wrote: Sat Feb 13, 2021 12:36 pm I can get better than that on the OSSC, with correct aspect ratio.

After I've fixed my bike indicators I can clear my table and get the info.
Cheers appreciated :)

@Cyprian So I assume we can't really create an 'easy fix' of injecting our own custom timing as it will effect the system too much? In that case I wonder if there is a slightly more complicated method we could use like the ossc, but not as expensive as the ossc :)
Post Reply

Return to “MEMBER BLOGS”