"Bus stuffing" like The Graduate.

[+SpiceWare]

Ah well, was just curious. While interesting as a tech demo, especially when you can take a photo to eliminate the flicker, I don't think 128 Chronocolour will be useful unless the framerate could be increased. My C= 1084 can handle a variety of framerates if it could handle down to 131p then the flicker would be exactly the same as Andrew Davie's Chronocolour examples...

Ran some tests with Jitter:

 

 

and it looks like my C=1084S can handle 190 scanlines at 82.74 fps.

 

 

That's a reduction of 72 scanlines, but I should be able to shrink Vertical Blank and Overscan to compensate for most of those.

[alex_79]

I did similar tests on my TV a while ago and it can handle between 360 and 244 scanlines without rolling (that is between about 43Hz and 64Hz).
It uses PAL aspect ratio (scanlines closer together) from 288 lines and up and NTSC one from 287 and below.

The strange thing is that I can actually get a stable picture with lower scanline counts:
With 122-180 scanlines (which is half of the supported values), I get a stable picture with 2 frames displayed in a "split-screen" arrangement.
The TV seems to just ignore the VSYNC signal which happens too early after the first frame outputted by the console, while it detects the second one and since the sum of the scanline counts for the two frames is in the supported range, it displays a stable picture.



With 82-120 scanlines I get a 'stack' of 3 frames and so on...

[+SpiceWare]

My 1084 does the split screen too, don't recall the range.

[Joe Musashi]

I tried "128bus_20161005.bin" on a PAL Junior.



Looks really great on a CRT! One thing that should be mentioned are the fine black lines that appear after each 8-pixel block. However, they also seem to be present in some of the pictures posted previously.

As already observed by alex_79, the PAL color glitch is only visible in the text demo.

[+SpiceWare]

Yeah, the fine black lines are a known side affect of using flicker to turn a 48 pixel display into a 96 pixel display. The same flicker technique is used to create the 128 pixel display, which uses mid-screen NUSIZx and RESPx tricks to get 4 extra copies of players to show up.

 

 

That PAL color glitch is really odd as the text display, line demo, and the monochrome^* car images all use exactly the same 6507 routines, the only difference is which routine in the C code fills the bitmap buffer.

 

 

If I recall correctly PAL sends the color signal over pairs of scanlines, so there's 576 lines of monochrome detail merged with 288 lines of color detail. The phase of the lines in each pair are reversed, so any transmission errors will automatically cancel out thus negating the use of a tint control that NTSC sets must have.

 

As a shot in the dark, in this build the TV Type switch will shift the bitmap up/down a scanline.

128bus_20161008.bin

 

^* two color in your photos due to Right Difficult=A, which is used to show player alignment

[Joe Musashi]

Yeah, the fine black lines are a known side affect of using flicker to turn a 48 pixel display into a 96 pixel display. The same flicker technique is used to create the 128 pixel display, which uses mid-screen NUSIZx and RESPx tricks to get 4 extra copies of players to show up.

Ah yes, forgot about the flickering DK also has this effect on the credit screen.

 

As a shot in the dark, in this build the TV Type switch will shift the bitmap up/down a scanline.

128bus_20161008.bin

 

Just tried it. The glitch is gone, unfortunately the image gets pushed down by about 1/4 screen in either switch position.

 

BTW is the source already available? Would be fun to experiment a bit with such a wide display

[+SpiceWare]

Just tried it. The glitch is gone, unfortunately the image gets pushed down by about 1/4 screen in either switch position.

I adjusted of VB and OS to make room for scanline shift - the C code probably needed that time. It didn't shift on the 1084, but it tends to be more tolerant of discrepancies than other displays I've used.

 

BTW is the source already available? Would be fun to experiment a bit with such a wide display

It will be, we're still hashing out the Bus Driver and don't want early versions of it floating around because they won't be supported by Stella.

 

That said, I've released the source for the DPC+ version of it.

[+SpiceWare]

Making some progress - I eliminated Overscan and added the ability to control how many scanlines the kernel draws. With the monitor set to the usual color adjustment (the knob "clicks" into this position) the colors are a bit more noticeable than before, and flicker's not nearly as bad.

 

Shrunk to there the monitor's updated at 77.82 fps.

increased color setting

 

Haven't implemented the auto-detect for alex_79's light sixer yet, and need to shrink Vertical Blank so more space can be allocated to the picture. Will release a new ROM once I do that, hopefully tomorrow night.

[iesposta]

Making some progress - I eliminated Overscan and added the ability to control how many scanlines the kernel draws.

Shrunk to there the monitor's updated at 77.82 fps.

Will release a new ROM once I do that, hopefully tomorrow night.

Is it tomorrow yet?

I know you moved on to the next demo.

Can you post the 77.82fps one?

 

I'm interested in out of spec tests with my different displays and Framemeister.

My DK game runs under 60; like 58.7 because we added Playfield and changed overscan due to going slightly over the cycle limit.

Am I crazy, or does the slower frame rate change the audio output?

I think it would having run in emulation Pal demos in NTSC and vice versa.

Edited October 20, 2016 by iesposta

[+SpiceWare]

Can you post the 77.82fps one?

I plan to get back to the 128 pixel demos this weekend, have a little bit left to do with the autodetect for alex's systems.

 

Am I crazy, or does the slower frame rate change the audio output?

I wouldn't expect the frame rate to change the audio output.

[Joe Stella]

THIS IS CRAZY!

[+SpiceWare]

THIS IS CRAZY!

 

I can't wait until we release the driver and see what ideas others come up with!

 

There's 16 datastreams that can be set to whatever increment you need so you can do things like use 0.20 to repeat playfield data over 5 scanlines, 1.0 for a "normal" increment, 2.0 for to access data that's intermingled with other data (useful when creating interlaced displays).

 

The datastreams can be flexibly mapped to both TIA registers and RAM. Some of my demos map 8 different datastreams to a single player, others map a single datastream to both players and the colors of both players, etc. Mapping to RAM makes it easier for a Kernel to jump to reposition code for objects (player/missile/ball) without the Kernel having to spend any precious cycle time figuring out what it needs to do.

 

We've still got some things to figure out though. I'm hoping we have it wrapped up early next year.

[alex_79]

That PAL color glitch is really odd as the text display, line demo, and the monochrome^* car images all use exactly the same 6507 routines, the only difference is which routine in the C code fills the bitmap buffer.

I investigated a bit on this issue. I have a cheap logic analyzer and connected it to the TIA output pins of my 4-switch while running the 128bus_20161005.bin demo and found that the first screen is outputting 263 scanlines instead of 262 as reported by Stella.

In this screenshot you can see a capture while running the first screen (text demo). There are 260 "Horizontal Sync" pulses to which you must add the 3 scanlines of Vertical Sync.

This one is for the second screen (line demo): Here you have 259+3 scanlines.

So it seems that the timing is incorrect in Stella emulation.

 

Edited November 6, 2016 by alex_79

[+SpiceWare]

I investigated a bit on this issue. I have a cheap logic analyzer and connected it to the TIA output pins of my 4-switch while running the 128bus_20161005.bin demo and found that the first screen is outputting 263 scanlines instead of 262 as reported by Stella.

Thanks for doing that! I can normally see jitter when that occurs, even when it's just 1 scanline off. Most likely the 30 Hz flicker used to create the display makes it difficult to see the jitter as there's nothing displayed in the same place on both frames.

 

So it seems that the timing is incorrect in Stella emulation.

Yep, known issue - the ARM emulator doesn't tell you how long something ran, just how many instructions it took. There's no easy way to correlate instruction count to time (SRAM access is faster than Flash Memory[ROM] access, MAM [cache] is disabled/enabled due to a bug in the chip, etc), so Stella thinks it ran in 0 cycles. That's why I tend to put in a way to see time remaining, such as Left Difficult=A in the RPG demo. In Stella it shows $24 and $1F for VB and OS:

 

While hardware shows $10/0F and $1D:

 

I'll have to add that to the 128 demo to figure out if VB or OS is out of time.

[+Gemintronic]

 

I can't wait until we release the driver and see what ideas others come up with!

 

There's 16 datastreams that can be set to whatever increment you need so you can do things like use 0.20 to repeat playfield data over 5 scanlines, 1.0 for a "normal" increment, 2.0 for to access data that's intermingled with other data (useful when creating interlaced displays).

 

The datastreams can be flexibly mapped to both TIA registers and RAM. Some of my demos map 8 different datastreams to a single player, others map a single datastream to both players and the colors of both players, etc. Mapping to RAM makes it easier for a Kernel to jump to reposition code for objects (player/missile/ball) without the Kernel having to spend any precious cycle time figuring out what it needs to do.

 

We've still got some things to figure out though. I'm hoping we have it wrapped up early next year.

 

I can get access to 256k ROM no SARA RAM boards here on AtariAge. Can be made batari BASIC compatible?

[+SpiceWare]

This only runs on the Harmony Cartridge or Melody Board.

 

I have no idea if anybody will make Bus Kernels for bB, it's not something I'll do. I will be writing a tutorial, along the lines of Collect, that will go over how to develop for Bus using C.

[+Gemintronic]

This only runs on the Harmony Cartridge or Melody Board.

 

I have no idea if anybody will make Bus Kernels for bB, it's not something I'll do. I will be writing a tutorial, along the lines of Collect, that will go over how to develop for Bus using C.

 

Can the whole game be programmed in C?

[+SpiceWare]

Just like bB there's kernels and stuff that are written in 6507. I'll be releasing a number of prebuilt kernels that people can use, so if one of those kernels will display what you need then all you need to worry about is the C portion of the program.

[alex_79]

[...] I can normally see jitter when that occurs, even when it's just 1 scanline off. Most likely the 30 Hz flicker used to create the display makes it difficult to see the jitter as there's nothing displayed in the same place on both frames.

It doesn't jitter, it's a steady 263 lines for the screen with the 32 character text, while is 262 for the second one (the one with lines) that you access by pressing the firebutton.

 

Also the dpc+ 32 char demo has 263 scanlines. This is the one that does show 262 lines in Stella, not the bus-stuffing one (which doesn't run in Stella yet). I mixed things up in my previous post...

[+SpiceWare]

Aha - I misread that and thought you were showing 2 frames of the same display.

 

ARM code = 0 cycles holds for DPC+ as well.