Hi,

First i'd like to greet everybody. I was first introduced to the Commodore 64 back in -85. Thats when i got my own C64. Although, there were already lots of software available, i interrested more and more about developing software myself. And i did some assembly coding, small demos and stuff. After two years i moved to Amiga but C64 is still the machine i like. Years passed and every now and then i studied the design of C64 and 6502. I become interrested about processors and compilers. Few years ago i started to develope my own multiplatform compiler toolchain. Progress is slow but maybe one day the whole thing is ready. Propably ever, but that doesn't matter. However, thing which lead to my problem is that, because i've finished my assembler, i thought it would be cool to code a little demo and test the assembler a bit. So, i coded a little iff-viewer for C64 and 1541.

Now into my problem. I tested the demo with Vice and everything seems to work. My assembler outputs a .prg file and it could be run in vice without problems. The demo loads an .iff-files from the device 8 and Vice kindly mapped the whole Windows directory as a big disk. So i though, well, the demo is ready. I want to run it in the REAL C64. Hell, it uses interlaced display and all. So i generated an .d64 image which contained my demo.prg and bunch of .iff files. That image didn't run in vice at first time but i sorted it out, maybe. I manage to generate a .d64 image which worked with Vice but when i used my MMC64 to transfer it to a real 1541 floppy the demo didn't work any more.

I have the C64 reference manual and the documentation there is very poor. Thats why i suspect that i coded the file handling such an incompatible way that it works in the Vice with certain circumstances but not in the real C64.

I include my file handling module here so somebody with good knowledge can check it out. Or point me to a place where i could find a proper documentation/examples.

Regards

Ok, i did some debugging with the real C64 and AR6 cartridge and found out that the file handling works perfectly. But only when i don't mess with IRQ frequency and register in $DD00. I checked the memory map and it turns out that IEC signals are driven by that register too, ops. I need it to switch CIA bank for an interlaced display.

So, my strategy is as follows:
1. implement multisourced IRQ handler(CIA and raster interrupts)
2. Don't touch to other bits in $DD00

Looks promising...

To switch graphics bank while loading, set dd00 to 0, then write the bank into $dd02 instead (the DDR). If you set the DDR bit to a 0, the input will float high. If you set the DDR bit to 1, it'll pull low.

Also, use an IRQ loader instead of the kernal loader. DreamLoad and Krill's loader are popular choices, and you can roll your own based on the Covert Bitops rants.

Can you give more info why bank should be switched in that way? Either way, the other bits must be preserved.



This isn't going to be a such a small demo as i first imagined... But you're right, i noticed that kernel load messes with i-flag and/or occasionally takes too much time in IRQ. As a solution i was thinking of using CIA driven NMI-interrupt, started during vertical blanking period. But the IRQ-loader would be more elegant solution.

Thanks

With some thought you can let kernal handle IEC bits at $dd00 and swap VIC-II bank with $dd02, without one affecting the other so no AND/OR needed, and it's safe to change one in IRQ/NMI and other in the main code.




This will only work with kernal routines if you keep your NMI under 40 cycles total and make sure it won't happen on bad line. That 40 cycle count includes 7 cycles for firing the NMI and another 7 cycles for RTI, leaving you 26 cycles which is enough for switching VIC-II bank but not much else.

Thanks for the info, I will try that consept. The NMI is going to be handled in the vertical blanking period, so there's no bad lines and only thing what it does is switch VIC bank and toggle one horizontal scroll bit. I think that fits to those specifications. BUT, i will need an NTSC/PAL detection to know what timer value i need to use. So, i'm seriously thinking the IRQ-loader thing.

They exist to solve this exact problem :)