Lynxdir mixed loader issue

[LordKraken]

Hello all,

 

The last Highlander of newcc65 speaking here (together with @Fadest obviously). This has its importance, as you will see later.

 

So to overcome the limits of the 256kb cartridge inherited from BLL, I have been show how to create a mixed cartridge. This is how it looks:

;; 256KB ROM
;#INTERNAL
;#TROYAN
;#BLOCKSIZE 2048
;#DIRSTART 896
;#BLL
;; 512KB ROM
#HACK2048
#BLOCKSIZE 2048
#DIRSTART 410
#EPYX
insert.o
odynexus.o
#DIROFFSET 896
#BLL
#EMPTY
#EMPTY
res/spr/img_splash.spr
res/spr/img_title.spr
... and all the files

 

So I just replaced my original BLL loader and replaced it with the Epyx one, and switch back to BLL format for the data.

I tweaked (well @Fadest did) the original loading function to take into account the 2048 alignment and the presence of a second CART.

 

THIS WORKS ALL FINE.

Program start, files are loaded, I can create ROM on 512kb, great!

 

But but but... now I get very little graphical glitches in a somewhat undeterministic way. The game does not crash, pixel are more or less located at the top left corner of the screen but when i start scrolling, they scroll away. I'm 100% sure I'm not writing anything there, otherwise I would see the same glitches with the BLL format...

 

Here is what it looks like for instance. Sometime the glitch is 20 pixel long, sometime a little longer. If I set yoff to 1 i dont see it. So it's like when I'm rendering my SCB, something is messing with them...

 

This sounds like a quite low level problem to me and after long hours trying to understand whats happening I'm without solution... 

Any thoughts?

[42bs]

To me it looks like the offsets in the directory are wrong. So it starts loading the actual data to early.

Did you try to add dummy entries in front of the garbeled sprite entries?

 

[sage]

14 minutes ago, LordKraken said:

So I just replaced my original BLL loader and replaced it with the Epyx one, and switch back to BLL format for the data.

I tweaked (well @Fadest did) the original loading function to take into account the 2048 alignment and the presence of a second CART.

 

which second cart?

and which alignment? there is no alignment.

anyway, without knowing what your spr look like and how/where you load them it is hard to say anything.

[LordKraken]

@42bs good idea, Ill try to add null data entry in front of every sprites.

 

@sage sorry I meant 2048 blocksize. And by CART I was just using the terminology from the code, but essentially what I meant is that the loading function is dealing with the new blocksize and the extra data.

[sage]

if you think it i a bug in lynxdir, please file a issue and add necessary files to reproduce it. esp the first sector of your rom.

Edited August 31, 2020 by sage

[LordKraken]

@Fadest (once again) suggested to test the mini loader (which I already did but stupid me forgot to remove insert.o so I wasn't going anywhere...) and guess what... It does work again and all the glitches are gone...

 

@sage would that help if I would give you the mixed epyx/bll version (with glitches) as well as the mini/bll version (without glitches)?

 

 

[LordKraken]

After hours of debugging and discussion, and countless failed ideas, with the help of @Fadest I discovered by chance that using the mini loader instead of the epyx loader actually removed all the glitches. Let's be clear here: it does not make any sense at all!?!

 

Then after a discussion with @sage, I just changed the execution adress of my insert file (from 0x2400 to 0xa030 because why not) and guess what?! All glitches are gone, independantly of the loader... And yes here again it does not make any sense at all... once again!

 

But at least I seem to have a working 512KB cartridge. We'll see if millions of hours of testing (yeah maybe a bit less) will undiscover the glitches again

 

Edited September 1, 2020 by LordKraken

[Fadest]

Is it a good news for @agradeneu ? He can draw 6 more levels without any ROM issue

Edited September 1, 2020 by Fadest

[42bs]

Gone are the good old times, where we tried to find super-cool compression algos to fit a 1GB game into 128k ?

 

Serious: Great news!

[LordKraken]

13 minutes ago, 42bs said:

Gone are the good old times, where we tried to find super-cool compression algos to fit a 1GB game into 128k ?

 

Serious: Great news!

Now we are in the days where artists do that kind of work for us ahah

[Fadest]

Also, as the most common PCB can handle 512k for the same price, there is no financial or technical reason to fight against the 128k or 256k limit.

But if it gives more space for assets, it does not change the constraints for code...

[+karri]

The key question of today is managing RAM. There should be no bytes in RAM that are not used for the level you are working on. My games discard the boot and init code after use. The cart loading stuff and keyboard handling stuff are not needed at the same time so they can share the same RAM area. I rather have multiple copies of the sprites and read them in with the level than waste space for managing assets.

And finally Handy Music is smaller than Chipper.

 

Perhaps it is time to create a new Handy Music template with all the space saving ideas and the enhanced UI functions by @Nop90. I really LOVE these gray palette during Pause. The checkInput routine that shares RAM memory with the loadCart function. This fits in some unused space by HandyMusic SFX area. So it is virtually invisible and it allows me to create lots of levels without a need to increase RAM usage (the loader is no longer in resident memory).

[Turbo Laser Lynx]

On 9/1/2020 at 2:24 PM, karri said:

And finally Handy Music is smaller than Chipper.

 

Perhaps it is time to create a new Handy Music template with all the space saving ideas and the enhanced UI functions by @Nop90. I really LOVE these gray palette during Pause. The checkInput routine that shares RAM memory with the loadCart function. This fits in some unused space by HandyMusic SFX area. So it is virtually invisible and it allows me to create lots of levels without a need to increase RAM usage (the loader is no longer in resident memory).

I wish it would be possible to have a template branch with chipper too, because trackers are kind of standard in "retro computing" /  "retro game development", it's probably easier to get more muscisians on board Lynx, we got miker for example who already did some excellent stuff. Of course I feel bad whining about this. When I think about it the current template already has everything you need for a game, so perhaps it's not really a big deal.

[sage]

chipper export -> handymusic

you have to tweak the instruments afterwards, but hey, there is nothing as a free lunch (or software).