Page 1 of 2
Nice Hires screens
Posted: Sat Apr 08, 2017 6:32 am
by Symoon
Hi all,
I'm going to an Atari meeting in France next Saturday: AC 2017 - for those interested, you can still subscribe until tomorrow evening.
http://www.yaronet.com/topics/187724-ac ... communique
A few Oricians should be there.
I'll probably bring an Atmos there. I plan to demo my fast loading tapes routines (if I don't forget them this time
), so I think I'll set up an "audio" slideshow, i.e. a WAV file with hires screens that will loop, and be loaded thru the tape port.
So far I have a few hires screens (including an Atari ST desktop
), I know there are some on CEO Mag disks, but if you guys want to be part of the slideshow, please send me your pictures in .TAP format this weekend
Re: Nice Hires screens
Posted: Sat Apr 08, 2017 9:10 am
by Dbug
You can use some of the slideshow demo if you want I guess:
http://miniserve.defence-force.org/svn/ ... lope/data/
Re: Nice Hires screens
Posted: Sat Apr 08, 2017 6:18 pm
by Symoon
Thanks, converting the screens back with the -f1 option seems to work like a charm
Re: Nice Hires screens
Posted: Sun Apr 09, 2017 3:15 pm
by Symoon
I think there's a small bug though. It seems Pictconv produces a header going from A000 to BF40 for a Hires screen, which is 1 byte too much (should stop at BF3F). This prevented the next screen to load with my fast routines, as it used the 1st data bytes to complete the previous loading I guess.
Apart from this, the slideshow from tape runs fast and fine
Re: Nice Hires screens
Posted: Sun Apr 09, 2017 4:17 pm
by Dbug
I guess that's the usual +1/-1 on the computation of the end address which has been plaging all our tape related tools for a long time:
Code: Select all
void OricPictureConverter::save_header(long handle,int adress_begin)
{
unsigned char Header[]=
{
// 0
0x16,0x16,0x16,
// 3
0x24,
// 4
0x00,0x00,
// 6
0x80,0x00,
// 8
0xbf,0xdf,
// 10
0xa0,0x00,
// 12
0x00
};
int adress_end=adress_begin+m_Buffer.m_buffer_size;
Header[ 8]=(unsigned char)((adress_end>>8)&255);
Header[ 9]=(unsigned char)( adress_end&255);
Header[10]=(unsigned char)((adress_begin>>8)&255);
Header[11]=(unsigned char)( adress_begin&255);
write(handle,Header,13);
}
Should probably replace the line by:
Code: Select all
int adress_end=adress_begin+m_Buffer.m_buffer_size-1;
Re: Nice Hires screens
Posted: Sun Apr 09, 2017 6:01 pm
by Dbug
Could you try this version?
- PictConv_0_25.zip
- Fixed the off-by-one error in the tape header when Exporting Oric images to tape format
- (1014.02 KiB) Downloaded 357 times
Re: Nice Hires screens
Posted: Sun Apr 09, 2017 6:41 pm
by Symoon
Thanks for the fast reply!
I manually corrected the addresses but will give a try indeed, and let you know.
Re: Nice Hires screens
Posted: Sun Apr 09, 2017 7:48 pm
by Symoon
Well it seems to work fine this time, thanks again
Re: Nice Hires screens
Posted: Sun Apr 09, 2017 8:57 pm
by Dbug
Good, will be in the next release of the OSDK
Re: Nice Hires screens
Posted: Sun Apr 09, 2017 11:05 pm
by Symoon
Re: Nice Hires screens
Posted: Mon Apr 10, 2017 7:44 am
by Dbug
Impressively fast compared to standard tape routines
Could probably use that to make an Oric version of Bad Apple, streaming the frames from the tape
Re: Nice Hires screens
Posted: Mon Apr 10, 2017 12:05 pm
by Symoon
Thanks ! I don't know Bad Apple, do you have a link?
The slideshow has a very small pause between each screen (something like half a second), and of course could be faster if only half a screen is loaded for instance. The problem is that according to the compression, the framerate could not be constant.
I'm currently working at having a better reliability for a majority of Atmos. I'm optimistic but I won't be able to achieve a 100% goal, some machines won't handle it. Also, the sound volume is quite sensitive - as one could expect. Too low or too high, and errors occur.
After that I'll have to think how the loader could be implmented for a more universal use (actually just located in #400...).
Meanwhile I also have produced an new coding which goes 20-30% faster. For instance the boat that loads in 3.2 seconds would load, IIRC, in 2.4 seconds. But I still have to write the decoding routine, which will have strong timing contraints, and I'm not sure it's possible yet. I'd need a month off for this
Re: Nice Hires screens
Posted: Mon Apr 10, 2017 2:56 pm
by Dbug
http://www.pouet.net/search.php?what=ba ... &type=prod
Basically it's originally an anime video made by fans, but it has been converted to a number of computers using various forms of compressions and encoding. The most promising one was actually using tapes to "stream" the video.
Assuming the code can be timed perfectly, it should be possible to read a bit of data, decode and display it, read some more, rince and repeat.
Maybe it would even be possible to encode the music as a stream of compressed YM registers along the video
Re: Nice Hires screens
Posted: Thu Apr 13, 2017 11:09 am
by Dbug
Btw, I added your bug report to the PictConv documentation page (at the end):
http://osdk.org/index.php?page=document ... e=pictconv
From now on, I'm going to try to get one issue registered for each bug I work on, so it will make it easier to know what was fixed, when, in which version of the SDK.
Re: Nice Hires screens
Posted: Thu Apr 13, 2017 8:46 pm
by Symoon
About Bad Apple, being in black and white only would allow us to store only 6 bits instead of 8. Removing the RLE compression would allow a constant framerate.
But having enough speed for several frames per second seems impossible to me.
Loading something compressed then uncompressing it seems impossible to me too, the problem with fast loading is that almost every cycle is used. Adding another decompression would mean having to add stop bits to have more time, thus a longer loading time.