duz anyone know if there was amsterdos for hardrives? do you think i can combine it with masterbasic
Dear rogerjowett, The questions you're asking me are to technical for me to answer, as I said before, I would recomend that you talk to the at, "Quazar" (Colin Piggot [email protected] or Website www.samcoupe.com , I can tell you that the people at these addresses given helped me so much in the past, their knowledge is ingredable. Sorry I can't help more but I really do advise you to get in touch with Colin Piggot, he's very helpful. Regards Derek. -derekjockey On 01/06/2011, Roger Jowett <[email protected]> wrote: > wow so interrupts are disabled during loading - i guess they woudl be > that makes sense - that was why the masterbasic audio routine sort of > slowed down during loading stuff then! > > On 31/05/2011, Leszek Chmielewski <[email protected]> wrote: >> Yes, but it will produce "jumps" between Frames and interlacing will also >> stop when loading (loading will switch the interrupts off) unless you >> code >> own loading routines. And again: Delta method will decompress on the fly, >> unless you are talking about decompression of additionaly compressed >> delta >> chunk. >> >> >> 2011/5/31 Roger Jowett <[email protected]> >> >>> so interlaced video could just display the same two frame for any >>> number of frames until it had loaded or decompressed another tow >>> frames... >>> >>> On 30/05/2011, Leszek Chmielewski <[email protected]> wrote: >>> > That is how delta compression (in Retro-X) works. It stores the >>> difference >>> > between two screens in s interleaved sequence of unchanged and changed >>> byte >>> > sequences (omniting 1 and 2 unchanged bytes so save more space and >>> > gain >>> > speed, so copy them to screen even if unchanged). >>> > You can store e.g.: >>> > 50 bytes are unchanged, so skip these 50 bytes by increase pointer of >>> > current screen adress by 50 >>> > 14 bytes are changed, so copy these 15 bytes from memory to screen >>> > 96 bytes are unchanfged, skip! >>> > 67 bytes are changed, copy... >>> > You can see, it is primitive, but allows to store many frames if there >>> are >>> > only small differences. You even do not need a flag byte becaues it is >>> > always the same sequence: Skips with size data and blits with size >>> > data >>> and >>> > bytes data. >>> > I wrote a decoder for Spectrum only (allowing ca 50 fps if the frame >>> > size >>> is >>> > below 2 kb), but I cannot code that good on SAM in Assembler, with all >>> the >>> > bank management. I think, the SAM can display 50 FPS Delta animations >>> with >>> > frame size of 3 KB (166 Frames stored on SAM 512=3.25 seconds >>> > animation >>> at >>> > 50 FPS) or 6.5 Seconds at 25 FPS. At 10 FPS (still fluid, 16,5) >>> > Seconds >>> can >>> > be stored) >>> > >>> > Best regards >>> > LCD >>> > >>> > >>> > >>> > 2011/5/30 Stefan Drissen <[email protected]> >>> > >>> >> All you need are the differences (without compressing anything). >>> >> Instead >>> >> of >>> >> saving raw screen$ data, you generate the difference between two >>> >> frames >>> as >>> >> optimized machine code that only updates the screen addresses that >>> >> need >>> >> updating. There is a tipping point at which it would be quicker to >>> simply >>> >> refresh the entire screen. You may also want to insert entire screen >>> >> refreshes every X frames to allow a fast forward. >>> >> >>> >> This cannot be that difficult. >>> >> >>> >> Regards, >>> >> >>> >> >>> >> Stefan >>> >> >>> >> -----Original Message----- >>> >> From: [email protected] >>> >> [mailto:[email protected]] >>> On >>> >> Behalf Of Roger Jowett >>> >> Sent: zaterdag 28 mei 2011 01:56 >>> >> To: [email protected] >>> >> Subject: Re: Loading stuff from machine code with the ROM functions >>> >> >>> >> ok this is it my last daft email to the gang of 4! >>> >> please >>> >> as i dont have a clu >>> >> if masterbasic compresses a screen when it saves it >>> >> what would happen if you take two screens from my animation >>> >> if you compress them both and look at teh two compressed screen fils >>> >> surely the difference between teh two comrepssed screens is teh tiny >>> >> onscreen difference between one screen$ and teh next - no i didnt >>> >> think so either but still clutching at straws is fun >>> >> surely once you have decompresed teh first screen the rest only >>> >> really >>> >> need to be the tiny differences that are made to that first image >>> >> though >>> >> i realise ol z80b is sturgling to get 4kb into video ram and that is >>> >> jsut with copying not reading from a port whichshe has to do to read >>> >> teh atom >>> >> is there no other way of ziping things up a bit please? >>> >> >>> >> >>> > >>> >> >
