Jump to content
IGNORED

60 fps video using SIDE 2


phaeron

Recommended Posts

Could be a number of things, but the adjustment most likely to help is brightness. Basically, the interleaved color/luma line pattern I'm using here doesn't work as well with NTSC as it does with PAL. PAL is designed to alternate one of the color axes on each scanline to combat hue shifts, which the TV takes advantage of by averaging color vertically. This has the side effect of blending down the color lines into the grayscale lines, effectively allowing the display of pixels with both controllable brightness and hue. Your scan converter may have been doing this due to internally using 4:2:0 processing or just a cheap chroma "comb filter" hack. NTSC displays don't do this and so we're more dependent upon visual blending there. Another problem is that the black level of the Atari is actually below NTSC black and so the color lines are very dark; this limits color reproduction for TVs that can't handle "negative color." Boosting the brightness of the color lines would help, but the way that GTIA modes 9 and 11 work make this difficult to do with the very limited amount of time available in the screen kernel and it would require special handling in the video converter for grayscale.

 

This method of video display would be amenable to other kinds of displays besides mixed modes 9 + 11, but I haven't found another method that produces nearly as good of a picture. I tried experiments with 2-bit and 1-bit luma to see if the higher resolution would make up for the loss in color depth, but even with aggressive dithering the display looked much worse than having 4-bit hue and 4-bit luma.

  • Like 1
Link to comment
Share on other sites

This method of video display would be amenable to other kinds of displays besides mixed modes 9 + 11, but I haven't found another method that produces nearly as good of a picture. I tried experiments with 2-bit and 1-bit luma to see if the higher resolution would make up for the loss in color depth, but even with aggressive dithering the display looked much worse than having 4-bit hue and 4-bit luma.

 

I experimented with 4-bit chroma and 2-bit luma with some success. Here are some emulator-only executables for comparing 2 and 4 bit luma: apac-movies.zip. I was thinking about adapting this to use your IDE techniques by using ANTIC mode 4 instead of mode 2, the drawback being that you only get 8 chromas that way due to the AN# ANTIC-to-GTIA encoding issue. As long as they are the "right" chromas for the subject matter, it could be an interesting option. It seems like most of the missing chromas are in the greens at least in PAL.

Link to comment
Share on other sites

You could double your effective vertical resolution, and most likely improve color blending on NTSC and SVideo displays by using "interlaced APAC".. In other words, in even numbered frames, even numbered scanlines are mode 9 and odd numbered ones are mode 11.. In odd numbered frames, this gets reversed. SO instead of depending on chroma pixel displayed below a luma pixel to "bleed over" and mix, youd effectively be using every pixel on the screen but showing chroma for 1 frame, followed by luma on the next. This halves your effective frame rate, and may flicker some, but on sharper displays or displays with less saturation/bleed-over, it may look better.

 

Or, if you really wanna try something crazy.. make it do COLRVIEW mode.. Your frame rate gets cut to 20fps, but you get full vertical resolution and 4096 colors..

fatima.gif

Edited by MEtalGuy66
  • Like 1
Link to comment
Share on other sites

This method of video display would be amenable to other kinds of displays besides mixed modes 9 + 11, but I haven't found another method that produces nearly as good of a picture. I tried experiments with 2-bit and 1-bit luma to see if the higher resolution would make up for the loss in color depth, but even with aggressive dithering the display looked much worse than having 4-bit hue and 4-bit luma.

 

Have you considered using PCIN mode ... that is, changing between Graphics 15 (mode E) and Graphics 10 (mode F with GPRIOR set to $80) ... you'd need to shift the mode 15 part of the display to the right by one pixel, and you'd also want to change COLBAK on the mode 10 lines, in this fashion: COLPM0 and COLBAK on mode 15 are the same, COLBAK on mode 10 lines becomes a 9th color. As there are no color palate changes involved, areas of the picture that mix the PFx and BAK colors can be dithered using checkerboarding to reduce flicker.

 

So for this method, you need a Graphics 15 and a Graphics 10 render for each frame, with color palettes arranged so that BAK and PF0-PF2 have identical settings in both renders.

 

You can get about 30 colors using this method. Might not be good for all movies, but for cartoons and such, you can get very nice coloring with very little flickering and banding, plus this mode does whites and greys a lot better than APAC or CIN mode.

Edited by Synthpopalooza
Link to comment
Share on other sites

I've shied away from frame-flickering techniques because they cause my HDTV to wig out -- the deinterlacing logic really doesn't like it.

 

Line-interlacing techniques could fare a bit better, but the problem there is that there's no time left in horizontal blank to do it. The normal-width player has 23 cycles of HBLANK time and it uses 12 of those to flip VSCROL+CHACTL+PRIOR and the other 11 to play sound. Every three lines there is an extra 9 cycles, but that's not very helpful, and by my reckoning I can only free up four more cycles on the critical lines (turn off display list DMA, raise horizontal scroll higher, and read three audio bytes directly from IDE). That's not really enough to do anything useful like flip a color byte.

 

What I do have, though, is sprites. Of the flip bytes I keep in A and X, VSCROL only cares about the lower 4 bits and CHACTL the lower 3, so the upper 4 bits are solely for PRIOR. This means that I can flip bits 4 and 5 of PRIOR trivially. The multicolor sprite bit is useless, but the fifth player bit can do a color change. Now, ordinarily this would be useless because the missiles can only cover 32 color clocks, but if I use the recently discovered sprite shift lockup bug, I can cover the whole screen with missile 0 and toggle it between P0 and PF3 to lighten the chroma lines a bit, which should brighten the picture and improve the color quality on NTSC. The video converter would still have to be modified to deal with hue 0 having a different luma but I don't think that would be hard to deal with.

  • Like 2
Link to comment
Share on other sites

  • 1 month later...

I would like to try it out on a real SIDE2. But I'm a bit confused which steps are required to play a demo video. Could somebody please post a step-by-step tutorial to bring a sample video to play on the real hardware? I'm especially confused about the way to "raw copy" the converted video file to a APT-compatible partition on my CF disk using a Windows computer. Maybe it is indeed very simple ?

 

greetings,

twh

  • Like 1
Link to comment
Share on other sites

This is F-SICK!

 

I somehow thought that motion-video may have never been in the cards for the A8bit... but, damn!

 

+500 KBytes/sec of throughput... and by using Antic pushing the limits on some CF-cards... It makes me wonder, though, what would the MAX bandwidth either ANTIC or Cart-port would support?... I would like to see if there is a real / absolute limit for the system for such I/O operations... Where is the red-line?

 

A big THANKS for such phenomenal attention to detail... Has anyone seen anything like this on the C64 realm, with stock chipset and I/O ports?

Link to comment
Share on other sites

A big THANKS for such phenomenal attention to detail... Has anyone seen anything like this on the C64 realm, with stock chipset and I/O ports?

 

Well. The question is if this is really "stock chipset". I mean the IDE adapters are from my point of view everything else then stock ? On the other side it is really just plug'n'play (SIDE2)

I've seen C64 video playback in a very decent picture quality. But I'm not sure if they just used the popular 16 MB memory expansions or if it was true HDD streaming.

However 60fps + digital audio is quite something to compete with :)

Link to comment
Share on other sites

hmm, my english is poor, but..

 

60FPS video is hard to play..

on small atari hardest.. because SIDE used something like low level access to sectors.. i dont know if this can read 60fps video.. maybe 25-30?

Link to comment
Share on other sites

OK, folks, had a go at this on REAL HW (800XL), beyond the comfort-zone of ALTIRRA, and it DOES NOT work, on any of my Ultimate-1MB 800XLs (RevC MoBo, socketed, ALPS-keyboard).

 

For those trying this at home, and for those already with successful trials, here's my setup:

  1. (x2) 800XLs (serial #s are 6K-9K apart, same construction, same version, one has Ultimate1MB v1 and the other v2).
  2. SIDE Cartridge I (from Zaxon's nightmare).
  3. CF cards for SIDE: one is an old Lexar 64MB (8x) and the other is a much newer SanDisk 4GB, capable of 30MBytes/sec.
  4. SDrive NUXX (SIO) for reading video player/loader.
  5. Files Tested: player is latest "smm2" version (Post #55, on this thread), and raw Video image (HD) is the 51,246 Kbytes version (or any other NTSC-encoded image, as posted on this thread).

 

Here is the process or step-by-step I used:

  1. First and foremost, find a CF card for which you will not mind DESTROYING its content.
  2. Download "HDD RAW Copy Tool" (http://hddguru.com/s...-Raw-Copy-Tool/). You can still back-up any existing CF's content, but be prepared for complete wipe-out.
  3. Insert CF card on your PC/reader, Open HDD Raw Copy utility, select Video HD-image file as source, "next", select your CF card as destination, "next" or "start copy".
  4. At this point ("supposedly"), a RAW transfer / copy will take place (I have not verified, at a byte-level, that identical copy is dumped on card, but it should).
  5. Copy Video Player (smm2 version) into SD card, insert back on Nuxx Drive, plug SDrive on SIO port.
  6. Plug SIDE-cart on A800XL (mine is SIDE-1 and I booted it with "SDX-switch" on), and insert CF card from #3 above, .
  7. I fire-up my 800XL with "HELP" button pressed (so I go into Ultimate BIOS). I disable "SpartaDos" and disable everything else, and set OS to Q-Meg (for quickly booting SDrive).
  8. Out of Ultimate-BIOS with "C" and let SDrive-NUXX loader take-over, select location of "smm2" player, and assign to "D1".
  9. "Help+Reset" so I go back to Ultimate-BIOS. Make sure XL-OS is selected, everything else disabled, and press "C" again. This time, SIDE boots (its own SDX image).
  10. On SDX prompt, I get the SIDE-loader/driver message (FJC), a garbage-string when running Lexar Cards, and a clear ID when running SanDisk card. Both are reported with "INVALID PARTITION". Almost identical to what I see in an earlier video, here on this thread.
  11. On SDX prompt, I type "cold /n", and 800XL reboots directly from D1 (SDrive NUXX) and successfully loads "smm2" player we set, there.
  12. As soon as player-load is finished, all I see is a screen filled with vertical green-bars, with a high-speed "BEEP" sound, stuck in there, nothing else. Happens to both machines, and both cards.

NOTES:

  1. When performing dump as described above, my Lexar Cards reported a speed of ~1 MByte/sec, while my SanDisk Ultra reported ~20 MBytes/sec.
  2. The effect or result described on #12 is exactly the same for each card.
  3. If anyone here has a better idea or a different tool to try the famous "RAW copy/transfer to CF" trick, I am all ears.
  4. The HDD RAW Copy Tool creates "compressed" images when pulling stuff out of the CF, into a file. I am not sure, however, if it applies such reverse-logic "decompression" while transferring back a File INTO the CF (which means it would probably destroy the Video-HD-file posted here).
  5. I would LOVE to see a version of SMM2 player for INCOGNITO-800 SIDE... That would be GLORIOUS to watch!

Thanks!

Link to comment
Share on other sites

Could this be made to work with IDE Plus? In a dual drive config pulling video from slave drive would be really cool. I have a dual-CF adapter on mine.

 

Well. The question is if this is really "stock chipset". I mean the IDE adapters are from my point of view everything else then stock ? On the other side it is really just plug'n'play (SIDE2)

 

On the same note, is plugging in a floppy drive considered altering the machine? Some of the IDE interfaces out there are true standards-compliant[ish] expansion cards that plug into ECI/PBI bus and don't require a custom OS, RAM-based OS or SDX to function.

 

PBI/ECI were actually designed with HDD interfaces in mind. There's even a little HDD picture above 130XE cart/ECI slot.

Link to comment
Share on other sites

Facuai, sounds like it's working, but you arent successfully dumping the stuff to the card.. Be sure and use the prebaked image that he provides in the thread, for testing, and make sure you have the right version of the player.

 

Also, rawcopy would not work on either of my windows machines to reliably write the card from the "0-block", ignoring all windows BS formatting, etc.. Neither would "DD for windows".. Evidently, that OS just lacks the low level control of the device where CF cards are concerned.. I also tried it in 2 different USB cardslot devices, and also in an adaptor, plugged directly in to the PATA on the motherboard.. Still, no.. nothing I did seemed to make it work..

 

You know what fixed it? DD on a real OS.. Grab a live-boot Linux CD off the web, like GPartEd, etc.. DD does it perfect for me every time under Linux.. Also, Mac OS X does a fine job, using DD..

Edited by MEtalGuy66
Link to comment
Share on other sites

Facuai, sounds like it's working, but you arent successfully dumping the stuff to the card.. Be sure and use the prebaked image that he provides in the thread, for testing, and make sure you have the right version of the player.

 

Also, rawcopy would not work on either of my windows machines to reliably write the card from the "0-block", ignoring all windows BS formatting, etc.. Neither would "DD for windows".. Evidently, that OS just lacks the low level control of the device where CF cards are concerned.. I also tried it in 2 different USB cardslot devices, and also in an adaptor, plugged directly in to the PATA on the motherboard.. Still, no.. nothing I did seemed to make it work..

 

You know what fixed it? DD on a real OS.. Grab a live-boot Linux CD off the web, like GPartEd, etc.. DD does it perfect for me every time under Linux.. Also, Mac OS X does a fine job, using DD..

I have had success with this USB product.

http://www.alexpage.de/usb-image-tool/download/

to put the image posted to a CF card and use the movie software to view.

also used Side2, 800xl with Ultimate installed. SDX bios off.

Boot with SIO to drive D1:....

Never tried with my Incognito 800 set up.

Link to comment
Share on other sites

Windows Vista and later have protection against programs doing raw writes to areas within mounted partitions. It's ordinarily a good idea but a problem in this case. The solution is to take the disk offline first using diskpart.exe or the Disk Management GUI. diskpart.exe can also be used to disable automounting temporarily. I use a Windows 7 x64 system to write to CF cards.

 

Also, the CF card can be tested first in emulation by mounting the raw CF card in Altirra. This will tell you whether the data made it onto the CF card properly.

 

The high-pitched beep sound usually means that the player is waiting on the CF card. It happens because timer 1 is freewheeling and not being set. There's logic in the player to try to delay and restart frames if the CF card doesn't begin transfers in time, but this probably needs some work.

 

It should be possible to adapt the player to IDEPlus connected to CF -- haven't looked into what would need to be changed besides IDE base, though.

Link to comment
Share on other sites

Both of my winboxes are XP, Phaeron.. And I tried Rawwrite, DD for windows, Winimage, and a host of other flashcard specific utils.. Could not get it written without some kind of offset that screwed up the whole works. Tried it on my Mac notebook with a cheap assed USB card reader, using DD, and it worked the first time.. Now, I just use the "Parted Magic" boot CD.. on my desktop, after Ive created the images using virtualdub..

 

 

Link to comment
Share on other sites

For the "stupid Atari tricks" section: by abusing IR mode 2 addressing, I figured out a way to get ANTIC to DMA playfield data straight out of an IDE interface of a SIDE 2 cartridge. This allows reading off the CompactFlash cartridge at 360KB/sec instead of 86KB/sec and in this way I was able to boost the frame rate of my old video player all the way to 60 fps, while still playing 15KHz audio

 

Was this player originally intended to operate using SIO?

Link to comment
Share on other sites

(...)

 

Also, the CF card can be tested first in emulation by mounting the raw CF card in Altirra. This will tell you whether the data made it onto the CF card properly.

 

(...)

 

 

 

THANKS for this key suggestion (and thanks all for the feedback and advice!)

 

Let me cut the chase, and report my findings (just trying to make this work in a simple way, for everyone as well):

  1. I re-transferred the ANIME HD-image (51,246 KB) with both "HDD Raw Copy Tool" and "USB Image Tool v1.62", on one of my WINDOWS 7 Dell laptop.
  2. I used my oldest CF card (64MB Lexar 8x), which it does reach 1.5MB/sec. throughput.
  3. I used a high-speed card/port adaptor for reading the CF (not the USB port) on my laptop's expansion port.
  4. I mounted the CF card on Altirra 2.30, directly as Drive, and loaded "smm-2" (post #55) player, on Altirra.
  5. In BOTH cases, IT WORKED PERFECTLY (raw-transfers from HDD Raw Copy and USB Image tool WORKED flawlessly, in Windows 7 + Altirra 2.30).

Now, here's the issue:

  1. I took the SAME CF card, with images from those two tools, and ran the test on my 800XL + SIDE-1 card + smm2 player, and IT DOES NOT work. I continue to get the exact same vertical-green bars with a high-frequency, high-pitched beep.
  2. Normal usage (SDX, loading, etc.) does seem to work well, though.

 

At this point I am beginning to believe that a have p.o.s. SIDE-1 cart. The above test fails on both my 800XLs as well as my Incognito-800 (I took the cart's cover off, so it could be plugged on the left-cart port, and de-activated SDX on Incognito BIOS. Same green bars / beeping sound).

 

I would have no problem editing / assembling source code (for local troubleshooting purposes), or any other homework (if needed) to try to troubleshoot or isolate a faulty area of it. I would really like to know why it is not working on my end, though...

 

Any other comments / advice would be appreciated. THANKS!

Link to comment
Share on other sites

Oh.. I missed the fact that you were using a side 1 cart, in your earlier post.. They have some "issues".. After ramadaan (2 more weeks) I will be taking 2 side carts to warerat, for indepth operational analysis, and he will hopefully be working with candle to possibly come up with a "fix" that will provide increased stability for these carts..

 

I doubt theres anything "wrong" with your side cart.. I have 2 of them here that exhibit similar flakey behavior across a wide range of test machines..

 

Oh, and the last thing I'll say, Facuai is that altirra is not necessarily a good comparisson to real hardware in this case.. If windows is padding the image on the card for some reason, than it stands to reason that windows would know about such padding and know where to read the "first byte", taking this into account..

 

Like I said, both a8isa and I have made MANY of these videos and successfully written them to CF cards and played them on real hardware. He has used a linux box from the start.. I never had any success until I started using mac/linux to write the image to the CF card.

 

Edited by MEtalGuy66
Link to comment
Share on other sites

Well, the point of testing the actual CF card with Altirra is if that doesn't work either, then something is obviously wrong with the copy. The reverse testing is also possible -- if Altirra can see APT partitions written on the Atari, that would confirm that there is no offset that is screwing up the works.

 

I wrote my own utility for doing raw writes to CF, but I'm not going to release it until it has some reasonable protections against writing to the wrong drive.

 

Another likely possibility is that the player isn't doing something correct with regard to IDE initialization, as some CF cards are more tolerant against errors than others and there might also be some SIDE/SIDE2 state I'm not setting yet. Attached is a WIP for a unified NTSC/PAL player with a slightly better startup path. It still needs some work though, as it still might have some trouble recovering from a blown read. Two most likely scenarios for the player to get stuck are (1) display list going off the rails and (2) IDE interface is stuck in DRQ or BSY state.

 

Was this player originally intended to operate using SIO?

 

Uh, no -- SIO can barely handle even audio much less video. :)

 

Earlier versions of the player that I hadn't released were just based on a similar method to the MyIDE movie player, which is just to have a tight CPU loop reading bytes manually out of the IDE port and pushing them into a conventional framebuffer, with a periodic IRQ to play sound. The original MyIDE player ran at something like 6fps with 6KHz audio... through optimization I managed to get it up to about 8 fps with 15KHz audio with a quarter-size framebuffer, which is better but still pretty hard to watch.

movplay.zip

  • Like 2
Link to comment
Share on other sites

(..)

Attached is a WIP for a unified NTSC/PAL player with a slightly better startup path. It still needs some work though, as it still might have some trouble recovering from a blown read. Two most likely scenarios for the player to get stuck are (1) display list going off the rails and (2) IDE interface is stuck in DRQ or BSY state.

(...)

 

 

Once again, THANKS for the hard-work!

 

Tested this new player version (directly on HW). Shows the main message, SIDE initialize as "OK", then "press a key"... I press it and a get a beeping BLACK-SCREEN.

 

At this point, I am not doubting of the HD-image integrity, transferred to the CF. I actually downloaded WinHEX (HIGHLY recommended) and performed a COMPARE-function of your 51+MB FILE-image with SECTORS on the CF-card (starting from zero-offset in both) and found them to be IDENTICAL. In fact, Windows File-system CANNOT mount the content of the card after being imaged (which is a good sign, no FAT, no directory, no nothing). But it can flawlessly perform raw reads & writes.

 

On the contrary, I suspect the problem may be related to either my SIDE-1 cart or simply the combination of SIDE-HW with my CF. What really bugs me (on this latter scenario) is that the problem ALSO appears with my latest-gen SanDisk Ultra card, though... which then takes me back to the SIDE-1 cart itself... FYI, my two 800XLs are loaded with Ultimate-1MB (not sure if this could potentially have an impact on the problem)... I do not have a bare-bones 800XL to play with. Problem shows up identical on my Incognito-800 (same black screen after pressing any key)

 

If there are any other checks-points worth adding to your reader/code, let me know, so I can try to find at least WHERE the movie-player is being hosed by the SIDE cart... Trying to do my best, before giving-up this uber-feat on my hardware.

 

THANKS!

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...