| |
Majikeyric
Registered: Sep 2002
Posts: 83 |
Covertbitops loader, something I dont understand...
Hi,
I'm actually developing a game,
The upper part of the screen is hires bitmap and the lower one is text.
I need to load small data files (2Kb) while the display IRQ is running.
I'm trying the Covertbitops loader system with 1bit IRQ loader,
when I run my game in VICE (without true drive emulation) everything is fine : the display, the loading routine, the loading speed...
But when I run my program in VICE (with true drive emulation) or on C64 with my 1541U-2, the loading speed is slowwwwwwwwwwwwww and the display IRQ is delayed. The display is.... ugly....
I thought that only the 2bit irq loader could delay the IRQ (as stated in the doc). Then I don't understand this behaviour, What am I missing ? Should I save my files on the D64 with interleave ? I saved them normally...
Many thanks for your help! |
|
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
irq can only be delayed by disabling interrupts (sei) and some time later cli, thats all to it! you need a loader which doesnt use that instruction.
as for your issue, try it in vice with true drive emulation first, as "non true" is a shitty emulation and no wonder that it produces different results from the real system. |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
The behaviour you dscribe sounds as if the loader falls back to using KERNAL calls. With VICE and virtual drives, this is no problem, as the KERNAL calls in question are trapped and shortcut, so there is no IRQ disturbance. Not so with true drive emulation or actual hardware.
Do you run the install routine? Does it return an error? |
| |
Majikeyric
Registered: Sep 2002
Posts: 83 |
Thanks for your fast replies!
I call the INITLOADER routine at the beginning of my program but there is no return value...
Writing files with a certain interleave is very important ? or is it just to speed up loadings ? |
| |
Majikeyric
Registered: Sep 2002
Posts: 83 |
In fact the fastloader is not activated but I can't see why yet... I'm studying the source code....
Maybe I made en error when converting the loader source code to Acme format ?!! |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
maybe try to compile a binary with the original assembler, and use that.
and as an "end user" of loaders you dont really have to care about sector interleave, unless you want to make the next best demo ever :) certain interleaves with certain loaders are faster yes, it depends on a lot of stuff. |
| |
cadaver
Registered: Feb 2002
Posts: 1153 |
The loader can run in 3 modes:
1) IRQ loading with custom drive protocol
2) Kernal calls without serial access (IDE64, virtual device traps AKA true drive emu off)
3) Kernal calls with serial access
2 and 3 are actually the same code-wise but the loader tries to detect whether Kernal is doing serial access, and sets the "slowirq" variable in case 3 (read the documentation!) to tell you should expect unpredictable and long IRQ delays. Case 3 is also entered if the loader fails to detect a drive that supports drivecode and the custom protocol, so you should be prepared for it and maybe blank the screen completely when loading, or show an error message.
It looks like you have managed to break the loader so that it never enters the custom protocol mode, maybe something to do with the drivecode sending. |
| |
Majikeyric
Registered: Sep 2002
Posts: 83 |
Thanks for the explanations.
In fact, the problem came from the strings format:
I had converted all strings to petscii for Acme.
By letting them : raw, the fastloader works correctly now :) |
