SECTION CODE - Problem with chunks and FAST ram

[KONEY]

HELP!!

I'm building my first intro requiring 512Kb+. So far I manage to load everything not needing to be on CHIP in "SECTION CODE" and samples+gfx in "SECTION DATA_C".

Everything is OK, vasm builds and returns as expected:

vasm 1.8d (c) in 2002-2018 Volker Barthelmann
vasm M68k/CPU32/ColdFire cpu backend 2.3b (c) 2002-2017 Frank Wille
vasm motorola syntax module 3.11c (c) 2002-2018 Frank Wille
vasm hunk format output module 2.9b (c) 2002-2017 Frank Wille

Code(acrx2): 173552 bytes
ChipData(adrw1): 448728 bytes
Press any key to continue . . .

and the intro works OK with 512kb CHIP+512kb SLOW or with at least 1mb CHIP. But on my A1000 I have 512KB of chip + 8mb FAST and the code won't start, exiting with an ERROR CODE 103 (not free ram).

Replicating the configuration on WinUAE sorted the same results. This applies only for KS1.3, from KS 2.0 everything is fine. Also tried with ASM-PRO, same result. Looks like there is a problem with fast starting address.

I'm using Photon's Mini Wrapper, full code here https://github.com/KONEY/lost_octame.../TR-808_MAIN.s


I think it's a quite trivial problem but I can't figure out exactly what to do, I guess I need to find the largest non-chip mem chunk and pass it to... what? Also when running the program it won't even load, just exit so I wonder if any changes at code could sort any effect at all...?


Please, any help or example would be appreciated


Thanks

[Thomas Richter]

Originally Posted by KONEY

I'm building my first intro requiring 512Kb+. So far I manage to load everything not needing to be on CHIP in "SECTION CODE" and samples+gfx in "SECTION DATA_C".

Replicating the configuration on WinUAE sorted the same results. This applies only for KS1.3, from KS 2.0 everything is fine. Also tried with ASM-PRO, same result. Looks like there is a problem with fast starting address.

I'm using Photon's Mini Wrapper, full code here https://github.com/KONEY/lost_octame.../TR-808_MAIN.s

I have no idea what that is. But if the file fails to load on 1.3 only, then the binary uses hunk types or hunk sizes the 1.3 loader (aka "dos/LoadSeg") does not recognize, in particular how to indicate that a hunk has to go into chip mem. I suggest trying another linker, e.g. "BLink" from Aminet.

[Toni Wilen]

Does the system actually have big enough contiguous free chip ram chunk? Z2 fast vs slow RAM is not exactly equal and might cause slight memory usage differences.

(or perhaps it is the most common problem: different number of floppy drives)

[a/b]

Did you try avail to see how much of the 512KB base chip is available, and how large is the largest segment? If has to be at least 439KB (512KB minus wb screen, disk buffers, ...).

[mark_k]

Originally Posted by Thomas Richter

I have no idea what that is. But if the file fails to load on 1.3 only, then the binary uses hunk types or hunk sizes the 1.3 loader (aka "dos/LoadSeg") does not recognize, in particular how to indicate that a hunk has to go into chip mem. I suggest trying another linker, e.g. "BLink" from Aminet.

The problem might be due to vasm creating executables with RELOC32SHORT hunks.

You can use ShortRel to convert those to RELOC32 which does work on Kickstart 1.x.

There is probably a vasm option to tell it to only create reloc32 hunks in the first place too.

[phx]

Did you use a linker or did you let vasm generate the hunk-format executable with

-Fhunkexe

option? In the latter case you have to use the

-kick1hunks

option, as vasm will output OS2.0 compatible executables by default.

EDIT: Noticed that your error was 103. Probably there is just no Chip RAM region which is large enough with your A1000 config, as others suggested.

[KONEY]

thanks, i'll try everything. Anyway I did a test with asm-pro and the same problem happened.

I should have chip ram free, when using slow fast the chip ram is the same amount and it works.

[KONEY]

AVAIL with 512kb CHIP + 512kb SLOW: (WORKS!)

Type Available In-Use Maximum Largest
chip 457296 65936 523232 457296
fast 471416 45472 516888 471288
total 928712 111408 1040120 471288

AVAIL with 512kb CHIP + 512kb FAST: (ERROR 103)

Type Available In-Use Maximum Largest
chip 449032 66832 515864 447824
fast 479744 44512 524256 479208
total 928776 111344 1040120 479208

well there's a small difference, maybe I should run something like add44kb before. I'll do tests!

[a/b]

Yeah, your largest chip mem chunk is not large enough (~1KB too short). Try addk21k (this one is the most harmless, compared to the rest of the addXk family) or reduce the size of disk buffers.

[KONEY]

yes I just figured it out, it works! Do you know where I can find add21k? on aminet there's only a 36k version.

[Antiriad_UK]

Slightly off topic but I'd also recommend having your winuae config having a df0: and df1: as that reduces the chipmem as well. Quite a few error 103 comments on pouet when people attempt to run intros with a df1: (like the old days) so nice to catch those errors early and put in the readme/nfo.

[Radertified]

Originally Posted by KONEY

yes I just figured it out, it works! Do you know where I can find add21k? on aminet there's only a 36k version.

In the zone

[Don_Adan]

Seems you can too split your chip_c section on two chip_c sections. First large, about 440KB and second small about 9KB.

[KONEY]

Originally Posted by Antiriad_UK

Slightly off topic but I'd also recommend having your winuae config having a df0: and df1: as that reduces the chipmem as well. Quite a few error 103 comments on pouet when people attempt to run intros with a df1: (like the old days) so nice to catch those errors early and put in the readme/nfo.

Not OT, actually quite relevant. Thanks for the tip!

Originally Posted by Radertified

In the zone

grabbed, thanks!

Originally Posted by Don_Adan

Seems you can too split your chip_c section on two chip_c sections. First large, about 440KB and second small about 9KB.

And what should happen this way?

[Don_Adan]

Ok, seems my idea was not good, you must to fit chip memory different. first chip hunk must have about 447800 bytes, and second chip hunk about 1000 bytes.

[defor]

Are you sure you need all your data to reside in the chip RAM from the beginning? It's risky for your program to require such a large continuous block of memory on 512kB chip RAM machines (see Antiriad's comment). Maybe you can place some of your data to fast/slow memory and move them (possibly even decompress) later to the chip RAM only when needed? In other words: Detect that some of your data can easily overlap through the program's lifetime

[KONEY]

I do If you look at the source code you'll notice I even splitted .MED file into two parts and modified the player so that everything but samples will be loaded in fast ram. CHIP ram will be crammed to the rim with samples

[morbid]

Slightly OT but @hoffmann did a nice write up of how they streamed samples from disk "just in time" in the demo EON https://hoffman.home.blog/2019/04/27/eon/, (scroll down to the SAMPLE STREAMING section).

Perhaps you can use a similar technique and copy samples from fast ram to chip ram?

[KONEY]

nice read, thanks!