my 2600 playground

[ZackAttack]

literally just draws a bitmap

 

There is otherwise no fixed circuit hw between the cart. slot and the ARM - everything is done in sw.

 

The 2600 doesn't do 160 pixel wide bitmaps. Even with quad bus stuffing and flickering/interlacing that's a stretch. Does this mean you have modified the system as well in order to allow the ARM processor to directly access the TIA chip?

[RevEng]

The 2600 doesn't do 160 pixel wide bitmaps. Even with quad bus stuffing and flickering/interlacing that's a stretch. Does this mean you have modified the system as well in order to allow the ARM processor to directly access the TIA chip?

I count 32 characters across in his screenshots, which puts it at 128 pixels.

[TomSon]

I count 32 characters across in his screenshots, which puts it at 128 pixels.

 

Yes, it's a 32 char kernel - not a modified system. All the data is put into register immediate loads (with cycles to spare) so the drawing starts like this:

even_loop:
;                        AB  CD  EF  GH  IJ  KL  MN  OP  QR  ST  UV  WX  YZ  01  23  45
        TXT_2LINES_EVEN $77,$36,$77,$35,$71,$54,$56,$26,$26,$37,$55,$AA,$57,$E4,$77,$AE,DARK_BLUE,DARK_BLUE
        TXT_2LINES_EVEN $55,$45,$44,$45,$21,$54,$75,$55,$55,$42,$55,$AA,$51,$A4,$11,$A8,DARK_BLUE,DARK_BLUE
        TXT_2LINES_EVEN $76,$45,$66,$57,$21,$64,$55,$56,$56,$72,$55,$A4,$72,$A4,$77,$EE,DARK_BLUE,DARK_BLUE
        ...

and the macros seeded with the data to be displayed - with just a little cycle-handholding later on for bank switching and scanline end checks (50/60hz).

Obviously it's interleaved: in the default menu output I am using a 3x5 font doubled to 3x10 so the odd and even scanline data is the same to

minimize flickering. I've also got a 3x7 font menu in there but that flickers too much on my TV for my liking - the default menu in PAL60 looks excellent

to my eyes, at 50Hz bearable (but still ok).

[Thomas Jentzsch]

Tiara looks more powerful than Harmony or Encore. Have you estimated the cost if you would produce it?

[DirtyHairy]

 

Yes, it's a 32 char kernel - not a modified system. All the data is put into register immediate loads (with cycles to spare) so the drawing starts like this:

even_loop:
;                        AB  CD  EF  GH  IJ  KL  MN  OP  QR  ST  UV  WX  YZ  01  23  45
        TXT_2LINES_EVEN $77,$36,$77,$35,$71,$54,$56,$26,$26,$37,$55,$AA,$57,$E4,$77,$AE,DARK_BLUE,DARK_BLUE
        TXT_2LINES_EVEN $55,$45,$44,$45,$21,$54,$75,$55,$55,$42,$55,$AA,$51,$A4,$11,$A8,DARK_BLUE,DARK_BLUE
        TXT_2LINES_EVEN $76,$45,$66,$57,$21,$64,$55,$56,$56,$72,$55,$A4,$72,$A4,$77,$EE,DARK_BLUE,DARK_BLUE
        ...

and the macros seeded with the data to be displayed - with just a little cycle-handholding later on for bank switching and scanline end checks (50/60hz).

Obviously it's interleaved: in the default menu output I am using a 3x5 font doubled to 3x10 so the odd and even scanline data is the same to

minimize flickering. I've also got a 3x7 font menu in there but that flickers too much on my TV for my liking - the default menu in PAL60 looks excellent

to my eyes, at 50Hz bearable (but still ok).

 

That's more or less what I already suspected. In particular, the possibility of having the ARM autogenerate 6502 code that is run from RAM is interesting and would be a serious improvement over the harmony / melody. So, to second Thomas' question: have you thought about making this available to a wider audience?

[+SpiceWare]

Tiara looks more powerful than Harmony or Encore. Have you estimated the cost if you would produce it?

 

 

The ARM stm32f4 is definitely more powerful, faster clock, more ROM and RAM. That extra space would be very helpful for the speech samples in Draconian.

 

That the menu can be done on the Harmony, the use of register immediate load's the same thing we're doing with Fast Fetchers + datastreams in DPC+ and CDF.

 

For DPC+ the 32 character kernel has a number of SLEEP macros in it, so there's plenty of time to update color - problem is all 16 datastreams are already in use. Interleaving data would work to free up datastreams for color, it just complicates the logic to update the text.

 

CDF has 32 datastreams, so the data layout could stay straightforward. Additional cycles could be freed up by using the the new FastJump feature for loop control, though that'd probably be overkill.

 

 

edit: weird - the link to the ARM is drawn using black instead of the usual AtariAge blue

[Thomas Jentzsch]

That the menu can be done on the Harmony, the use of register immediate load's the same thing we're doing with Fast Fetchers + datastreams in DPC+ and CDF.

If its feasible, we should do that.

[TomSon]

Tiara looks more powerful than Harmony or Encore. Have you estimated the cost if you would produce it?

 

Yes.. and it would be quite easy to do - it is more a question of whether I want to do this; First I'd have to build >=100 to get the price down.

And if I would not only provide a pcb would need to get Atari carts. from somewhere and adapt them.. and I'm having enough hobby-time

filled up with the VecFever production already. At least I would know better how to avoid costly problems (in time/money) - at least the ones

I've hit with the VecFever

 

ThomasJ: I could loan one of my current backup Tiaras to you for a while if you want to take a look - seeing that you live next door.

[Thomas Jentzsch]

Yes.. and it would be quite easy to do - it is more a question of whether I want to do this; First I'd have to build >=100 to get the price down.

And if I would not only provide a pcb would need to get Atari carts. from somewhere and adapt them.. and I'm having enough hobby-time

filled up with the VecFever production already. At least I would know better how to avoid costly problems (in time/money) - at least the ones

I've hit with the VecFever

I don't know the exact sales of Harmony, but I am sure they are way higher than 100. It all depends how cheap and powerful your design is. Of course there would be competition between Harmony and Tiara, so the sales would probably a bit lower. Also the Melody option of Harmony allows people to design much advanced games, so that should also be an option for Tiara.

 

I you want to go this route, you should get in contact with Al. He might be able to help with build and sales.

 

ThomasJ: I could loan one of my current backup Tiaras to you for a while if you want to take a look - seeing that you live next door.

Cool! I would love to see this in real life action.

[TomSon]

Also the Melody option of Harmony allows people to design much advanced games, so that should also be an option for Tiara.

 

 

Cool! I would love to see this in real life action.

 

I assume the 'Melody' is a stripped down version, or the Harmony has some extensions on top ?

 

The probably smallest, similar project I've brought up so far is the C64 SuperKernal, basically a Tiara pcb cut to the

barest bone one could think of. This shows how small a game-Tiara could be - for a single game cart. of at least 768KB

uncompressed plus permanent data storage for scores/options or more compressed (in the VecFever

firmware all cartridges are compressed, for example).

Probably more could be squeezed in with a bit of work but the above spec. would exist after just a day or two.

You may would want the capability to add more than one cartridge and a dedicated menu since this is probably

quite a bit for one game alone..

[Thomas Jentzsch]

I assume the 'Melody' is a stripped down version, or the Harmony has some extensions on top ?

Melody is basically a Harmony, but without the option of loading games from SD or via USB. So its tailored for selling games. There also exists a further stripped down, cheaper version (Aria) to reduce costs even more.

 

So you can see, that the price for your board is essential for its success.

[TomSon]

!!! Massive thanks to RevEng for helping me with a Tiara 7800 menu !!!

 

I've just finished the 7800 menu and tested it for a while so here are a few (rather bad, sorry)

pictures as proof.

so - a 2600 Tiara can run in 7800 mode and start 2600 games, that is implemented and working.

 

How is this done ? I detect the 7800 and behave differently in time to weave my way through

the 7800 BIOS checks to inject something into the 7800. This is tested on a PAL 7800 but should

work equally on the NTSC one and pretty much all patched BIOS versions, too, since all of them

need to check for a 2600 cart. - which I base my detection and handling on.

 

This is excellent since it allows me to already test quite a bit of a 7800-Tiara, esp. Maria access,

on near-final hardware. And having a 7800 menu is obviously very nice for a 2600 multicart.

Plus since one can actually detect NTSC/PAL on a 7800 (and not on a 2600) automatically and come

up in the correct menu, too, which is also nice.

 

So my next retro hw project is most likely settled - a proper 7800-Tiara.

[Thomas Jentzsch]

Plus since one can actually detect NTSC/PAL on a 7800 (and not on a 2600) automatically...

Not 100% true for the 2600 anymore...

[TomSon]

Not 100% true for the 2600 anymore...

 

You know, when I was writing that I already had at the back of my mind the expectation/hope that someone might mention something

Are you certain that this reliably works on a Harmony - what are the frequency precision +/- percentages there ?

I am specifically asking because I had to handle these (and know that they can change from part to part) so you need a known error margin

that is small enough.

 

Nonetheless I'll investigate this since I should be able to get the same measurements up there, too. Plenty of unused timers to play around

with.. Obviously no need to check for a 7800 via this, too, I already know when one is present..

[+SpiceWare]

Plus since one can actually detect NTSC/PAL on a 7800 (and not on a 2600) automatically and come

up in the correct menu, too, which is also nice.

As Thomas says, not true anymore. We can even detect if it's a SECAM 2600.

[+SpiceWare]

Are you certain that this reliably works on a Harmony - what are the frequency precision +/- percentages there ?

I was tracking down that link so missed your reply. That link talks about the clock rate differences between the systems. We had a number of people test it and while there were some variations the results the type of console was consistently detected.

 

This is the routine that runs during the "splash screen" for Draconian. The console detection test runs for 1 frame.

void SplashVerticalBlank()
{
    MODE++;
    
    if (MODE == 0x81)
    {
        T1TC = 0;           // make sure timer starts at 0
        T1TCR = 1;          // turn on timer
    }
    else if (MODE == 0x82)
    {
        T1TCR = 0;          // turn off timer
        
        if (T1TC < (0x11e8ff + 0x11d329)/2)
            MM_TV_TYPE = NTSC;
        else if (T1TC > (0x11fd2b + 0x11e8ff)/2)
            MM_TV_TYPE = PAL;
        else
            MM_TV_TYPE = SECAM;
        
    }
    else // if (MODE == (0x80 + 60))   // 1 second delay for testing splash screen line count
    {
        // eventually this will be the time the AtariAge splash screen is displayed
        MODE = 1;   // menu
    }
}

---

MODE is the game mode variable. If bit 7 is on it's in Splash Screen mode. If MODE = 0 then the game is active. If MODE = 1 the menu screen's active. Additional modes could be 2 for high score list, 3 for easter egg, etc. though I don't think I'll have space for those this time around as the digital samples will take up a lot of room.

 

From the manual for the ARM processor used in the Harmony:

• T1TCR = Timer 1's Timer Control Register. The TCR is used to control the Timer Counter functions. The Timer Counter can be disabled or reset through the TCR.
• T1TC = Timer 1's Timer Counter. The 32-bit TC is incremented every PR+1 cycles of PCLK. The TC is controlled through the TCR.

[TomSon]

As Thomas says, not true anymore. We can even detect if it's a SECAM 2600.

 

Again, what are the error margins ?

Come to think of it - what are the error margins on a 30-year old frequency part you test against ?

Sorry, I am also a physicist by education so I usually wonder about these.

The clock rates I see are all within a 1% error margin (PAL/SECAM/NTSC). To put this into perspective:

the internal clock accuracy of modern uProcs -the STM32F4 again- is 1%.

[Thomas Jentzsch]

Probably the ARM used in Harmony has a higher accuracy.

[+SpiceWare]

 

Again, what are the error margins ?

Come to think of it - what are the error margins on a 30-year old frequency part you test against ?

Sorry, I am also a physicist by education so I usually wonder about these.

The clock rates I see are all within a 1% error margin (PAL/SECAM/NTSC). To put this into perspective:

the internal clock accuracy of modern uProcs -the STM32F4 again- is 1%.

 

I didn't calculate error margins, but you can see test results from various people in the post Thomas linked to. Basically what we saw were timer values (in hex):

• 11D3xx = NTSC
• 11FDxx = PAL
• 11E8xx = SECAM

I also have the TV-Type as a menu option so the player can override it if it was detected incorrectly.

 

[Thomas Jentzsch]

The frequency difference between NTSC and PAL is about 0.9% and SECAM is in the middle. So the error margin should be lower than 0.225% (0.9%/4).

[TomSon]

Sigh, I won't get into the details of how to calculate error margins - and how many data points you need for a higher precision - because

I do realize that is both tedious and probably my reaction just a result of my studies and background.

Nonetheless .2% isn't really low, remember that the precision of both the uProc and the 30+ year old clock generator have to be taken

into account. Nonetheless, 'on average' this will work better than no detection whatsoever so I agree, this is a detection scheme.

Just not a 100% reliable one, until proven.

[Thomas Jentzsch]

Sigh, I won't get into the details of how to calculate error margins - and how many data points you need for a higher precision - because

I do realize that is both tedious and probably my reaction just a result of my studies and background.

I am interested.

[DirtyHairy]

Sorry, I am also a physicist by education so I usually wonder about these.

 

Hah, another physicist Sorry for derailing the discussion, but I have to ask: what domain of physics did you work on? I used to do research in theoretical particle physics

[+SpiceWare]

Could always do a call for testing like we did for Bus Stuffing. For that we saw 5 failures out of 78,which was enough for me to cancel plans of using BUS Stuffing for Draconian. That turned out OK though, the creation of CDF with FastJump^* meant I was able to pull off everything I thought I'd need BUS for.

 

I didn't do a call for testing for console detection because I felt the menu option as a fallback was good enough. In contrast, for BUS there's no fallback if it doesn't work.

 

 

^* Fastjump is basically JMP $0000 where the CDF driver replaces $0000 with the address of the next single-scanline-kernel to run.

[TomSon]

 

Hah, another physicist Sorry for derailing the discussion, but I have to ask: what domain of physics did you work on? I used to do research in theoretical particle physics

 

solid state physics: semiconductors That reminds me to visit CERN - I wanted to visit for ages..