I know I have to move to the latest version, but I need time and energy to migrate.. Could you provide a quick and dirty guide about how to do it?
![Smile :)](./images/smilies/icon_smile.gif)
That will be difficult, Dbug, but I will try to see if I can narrow the issue a bit more. The thing is that I have to add extra bytes to the main program (in a certain range, no more no lessDbug wrote:Not that I'm aware, but it's always possible
If you could write a minimal test case that exhibits the problem, would be helpful.
Code: Select all
std::vector<unsigned char> compressedBuffer;
if (m_CompressionMode==e_CompressionFilepack)
{
// So the user requested FilePack compression.
// Great, we can do that.
compressedBuffer.resize(fileSize);
gLZ77_XorMask=0;
size_t compressedFileSize=LZ77_Compress(fileData,compressedBuffer.data(),fileSize);
if (compressedFileSize<fileSize)
{
// We actually did manage to compress the data
fileData=compressedBuffer.data();
fileSize=compressedFileSize;
fileEntry.m_CompressionMode=e_CompressionFilepack;
fileEntry.m_StoredFileSize=compressedFileSize;
fileEntry.m_SectorCount=(fileSize+255)/256;
}
}
Code: Select all
fileEntry.m_StoredFileSize=fileSize;
fileEntry.m_FinalFileSize =fileSize;
fileEntry.m_SectorCount=(fileSize+255)/256;
fileEntry.m_FilePath =fileName;
fileEntry.m_CompressionMode=e_CompressionNone;
Well, LZ77 is based on pattern matching and repetition, so adding bytes in some places may just may make this place match another one.The thing is that if I add the extra bytes to the main program, the compressed size is (believe it or not) smaller (12800 vs 12804)
Just one question: Are you using the FilePack as in my demos, or did you integrate it in your own build script? If you integrated in your build script, did you do the correct number of loops so all the programs that include FloppyBuilder generated files actually get recompiled/reassembled with the correct data?When compressing and with no extra bytes added the generated floppy_description.h file the sector info is:
FileStartSector .byt 4,7,7,8,9,10,11,12,4,10,12,4,6,7,8,10,13,14,9,7,1,8,16,7,2,11
But the debugger shows that the stored information for the start sector is :
04 07 06 07 08 09 0A 0B
Code: Select all
:: Call FloppyBuilder once to create loader.cod
%osdk%\bin\FloppyBuilder init floppybuilderscript.txt
set FLOPPYPASS=-
:Loop
echo %FLOPPYPASS%
:: Call XA to rebuild the loader
ECHO.
ECHO Assembling bootsectors
%osdk%\bin\xa -DASSEMBLER=XA sector_1-jasmin.asm -o ..\build\files\sector_1-jasmin.o
IF ERRORLEVEL 1 GOTO Error
%osdk%\bin\xa -DASSEMBLER=XA sector_2-microdisc.asm -o ..\build\files\sector_2-microdisc.o
IF ERRORLEVEL 1 GOTO Error
%osdk%\bin\xa -DASSEMBLER=XA sector_3.asm -o ..\build\files\sector_3.o
IF ERRORLEVEL 1 GOTO Error
ECHO.
ECHO Assembling loader
%osdk%\bin\xa -DASSEMBLER=XA loader.asm -o ..\build\files\loader.o
IF ERRORLEVEL 1 GOTO Error
::IF NOT EXIST BUILD\symbols GOTO NoSymbol
popd
:: Assemble the data
pushd resdata
ECHO.
ECHO Assembling resource data..
::%osdk%\bin\xa -DASSEMBLER=XA resource_data.s -o ..\build\files\resource_data.o
for %%f in (*.s) do (
ECHO Assembling %%f..
%osdk%\bin\xa -DASSEMBLER=XA %%f -o ..\build\files\%%~nf.o
IF ERRORLEVEL 1 GOTO Error
)
popd
:: Let's assemble the engine
echo Assembling OASIS...
::
:: Set the build paremeters
::
CALL osdk_config.bat
::
:: Launch the compilation of files
::
CALL %OSDK%\bin\make.bat %OSDKFILE%
pushd floppycode
:: Call FloppyBuilder once to create loader.cod
%osdk%\bin\FloppyBuilder build floppybuilderscript.txt
if "%FLOPPYPASS%"=="--" goto EndLoop
set FLOPPYPASS=%FLOPPYPASS%-
goto Loop
:EndLoop
True, if modulo 256 that does not change anything, I guess it's worth keeping it uncompressed.Chema wrote:I knew the code is good enough as to detect if compressing was worth it (thought I'd say maybe check not only if the size is less but maybe have some kind of margin, such as if the compressed data uses less sectors).
What I suggest is that you look at the code of the FloppyBuilder, and look at it with new eyes.Chema wrote:All the times I end up with a header file containing the correct sector information, but with the actual data in disk containing different data (always the same I posted). Probably it is related to the thing that the compressed size is too close to the limit to include one extra sector or something like that.
Well, my idea was to load the existing file before saving the new one, and if identical output a different error code to indicate that we don't need any more passes.I would suggest that you generate a copy or temporal file with the information about sector/track/size whatever and check it against the last calculated to see if no more passes are needed.
Well, there's been quite some changes since then:Chema wrote:I am still using version 0.018
What I suggest is first to try to fix the gaps to get a working floppy structure.Chema wrote: ↑Wed Aug 30, 2017 8:20 pmI removed compression and interleave and tried in Oricutron (and in Euphoric too). Everything worked perfectly. I attach the disk image. I moved to Cumulus (a clean empty image) and the red bar appeared. I also attach the disk image. If you examine both files with an hex editor you'll see differences in the gap length (the 0s and 22s) but the important thing is that several pages are wrong by 1 byte, starting in 1 instead of 0 (I think the first is ok). So 1 byte is missing from the stream and goes undetected.
Code: Select all
for (int i=0;i<gap2-12;i++) trackbuf[offset++]=0x4E; //trackbuf[offset++]=0x22;