exxos's Atari, Amiga & retro forum

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:



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! ;)

sounds cool

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).

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.

Steve wrote: 12 Feb 2021 22:54 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

mrbombermillzy wrote: 12 Feb 2021 21:35 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

@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.

mrbombermillzy wrote: 13 Feb 2021 00:14 @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: 13 Feb 2021 00:14 @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: 13 Feb 2021 00:14 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.

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

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.

stephen_usher wrote: 13 Feb 2021 12:36 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 :)