| |
Krill
Registered: Apr 2002
Posts: 2825 |
Release id #205500 : Freespin
Allow me to comment on some tech details here, as i don't have an FB account to comment on the blog.
Great idea about the table-less 3:2 GCR-compliant codec to have maximum spare space for actual payload effect code. =)
(But table sizes of traditional decoding schemes aren't all that big, really.) |
|
... 52 posts hidden. Click here to view all posts....
|
| |
Krill
Registered: Apr 2002
Posts: 2825 |
Quoting JackAsserIt’s not timing critical, CRTs adapt So do modern flatpanel monitors (if they still have Y/C or composite input), albeit with arguably lower tolerances while often doing weird things like insisting on interlace output. =)
I'd say it still is timing-critical, but not all that tight. As long as a scanline is about 64 µs long* and a frame/field about 1/50 s for PAL-ish output, all should be good. :)
* Which is why it's 63 cycles on a PAL machine with slightly below 1 MHz and 65 cycles on NTSC with slightly above 1 MHz. |
| |
JackAsser
Registered: Jun 2002
Posts: 1987 |
Quote: Quoting JackAsserIt’s not timing critical, CRTs adapt So do modern flatpanel monitors (if they still have Y/C or composite input), albeit with arguably lower tolerances while often doing weird things like insisting on interlace output. =)
I'd say it still is timing-critical, but not all that tight. As long as a scanline is about 64 µs long* and a frame/field about 1/50 s for PAL-ish output, all should be good. :)
* Which is why it's 63 cycles on a PAL machine with slightly below 1 MHz and 65 cycles on NTSC with slightly above 1 MHz.
That's what I mean with not timing critical. You can be quite off on the VSYNC and it'll still lock. HSYNC is ofc a bit more critical. |
| |
Krill
Registered: Apr 2002
Posts: 2825 |
Quoting JackAsserHSYNC is ofc a bit more critical. Yes, there probably was a reason why they replaced 64-cycle NTSC VIC with the 65-cycle one. =)
And as for timing-critical, i thought this mostly means having a stable timing (not having exactly X time for thing Y).
Pretty sure that randomly having +/- 1 cycle per line and possibly +/- a few cycles/lines per frame isn't all that feasible across most video output devices. |
| |
JackAsser
Registered: Jun 2002
Posts: 1987 |
Quote: Quoting JackAsserHSYNC is ofc a bit more critical. Yes, there probably was a reason why they replaced 64-cycle NTSC VIC with the 65-cycle one. =)
And as for timing-critical, i thought this mostly means having a stable timing (not having exactly X time for thing Y).
Pretty sure that randomly having +/- 1 cycle per line and possibly +/- a few cycles/lines per frame isn't all that feasible across most video output devices.
Ofc! Stable timing is required. |
| |
Quiss
Registered: Nov 2016
Posts: 37 |
Quoting Krill
Pretty sure that randomly having +/- 1 cycle per line and possibly +/- a few cycles/lines per frame isn't all that feasible across most video output devices.
Not sure about video grabbers etc., but at least my PAL 1802 was actually kind of fine with different line "widths" (i.e., a jittery hsync position)
It then takes a few lines to "adjust" to the new hsync offset, moving towards it at about 1 pixel per line. So you get a diagonal. Could maybe be used for tech-techs, if you really want to.
Didn't try on the 1084. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11100 |
Quote:Not sure about video grabbers
i am willing to bet they hate this sort of thing. a lot. :) |
| |
enthusi
Registered: May 2004
Posts: 674 |
You can check with the Atari2600 folks, there it is only software that determines the size of a frame (and hence PAL/NTSC) and it often varies even within (commercial) games depending on scene /o\
http://www.digitpress.com/library/techdocs/vcs_scanlines.htm |
| |
Krill
Registered: Apr 2002
Posts: 2825 |
Quoting enthusiYou can check with the Atari2600 folks, there it is only software that determines the size of a frame (and hence PAL/NTSC) and it often varies even within (commercial) games depending on scene /o\
http://www.digitpress.com/library/techdocs/vcs_scanlines.htm Seems like that is about number of lines per frame only, not length/duration of individual lines. |
| |
enthusi
Registered: May 2004
Posts: 674 |
Oh, yes of course.
HSYNC is (and must be) stable. And that is part of the video hardware (TIA), naturally. Or it wouldn't be 'racing the beam' but rather 'dragging the beam' :) |
| |
willymanilly
Registered: Jan 2016
Posts: 27 |
I'm not game to use my real hardware to run this demo so I've included "Drive GPU" support in Z64K (WIP - still needs a bit of work) which adds support for this demo.
For those who want to try it now, the demo doesn't play reliably in Z64K yet but it does play the sounds and graphics reasonably well when it does work. I have had it almost reach the end a few times but in most cases will spasmodically crash relatively early in the demo. note: If the disk track is not sitting at track 2 after the drive code is loaded and run, you will need reset and try again before switching to the drive GPU in machine settings and opening/closing the lever by reloading the same disk. http://www.z64k.com
It could be a number of reasons but I'm suspecting Z64K is having issues with correctly handling the bit banging of the track stepper which possibly causes reading of data from wrong track, eventually causing the demo to crash.
Does anyone have any info on what the mechanical delays are for the stepping motor on real hardware that should be taken into consideration for accurate emulation? |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 - Next |
