| |
Bregalad Account closed
Registered: Jul 2008 Posts: 42 |
Loading files
I'm a total newbie on the C64 but not on the 6502.
I'm trying to do a simple programm and I'm trying to sucessfully load a separate file into memory manually exactly as describled here
But I keep getting error #4 (file not found) although the file exists, I tried both with and without the " symbols arround the filename.
BTW if anyone know something better than the Kernal routines for loading files let me know, so that I can use zero page without worrying about anything, which is something I'd really like to do. I found a couple of so-called "fastloaders" arround but they are hard to understand for a newbie and I don't know howell emulators supports them (Metal Warrior freezes in Vice if I enable the fastloader). |
|
| |
hollowman
Registered: Dec 2001 Posts: 474 |
Perhaps its just the wrong case on the filename? Check in memory with a machine code monitor that the name looks exactly as on disk, or try with "*" as filename and see if that loads anything
Pretty much all loaders work fine in latest version of vice, is true drive emulation turned on?
If you are comfortable with crossassemblers you can try dreamload or ask Krill for the latest version of his loadersystem.
But for something easier to just try out and get started there's the older versions of Krills loaders Plushdos which has a nice interface and Fixup #$00 which has the loaders as source code for tass. |
| |
Bregalad Account closed
Registered: Jul 2008 Posts: 42 |
You are right it was the wrong case ! (as PC uppercase = C64 lowercase this is a headache)
However it skips the 2 first bytes, and that regardless if the file is a PRG file or a SEQ file. Any idea how to bypass this ? |
| |
chatGPZ
Registered: Dec 2001 Posts: 11386 |
normally the first two bytes are used as the load address, the kernal routines will either use that, or let you ignore it. (other custom loaders might let you use it for data though) |
| |
Monte Carlos
Registered: Jun 2004 Posts: 359 |
The first two bytes point on the memory location the file is loaded. They are not written into ram, they are just read to initialize the destination pointers.
Monte
|
| |
Monte Carlos
Registered: Jun 2004 Posts: 359 |
Hey Groepaz,
two .... the same thought, heh?
|
| |
Bregalad Account closed
Registered: Jul 2008 Posts: 42 |
Okay now I can load files. However, as long as I use Kernal I have risk of conflicting variables with my program and this is bothering.
Which memory locations should be considered safe to use, and which ones should be keept intact for the kernal ? It seems the Kernal uses most of zero pages, and that it also use some memory at $200-$3ff range (software interrupt vectors for instance, altough they're undocumented in the official docs it seems).
Something that comes in mind is that I could have a copy of the zero page somewhere else, and every time I use Kernal I exchange the true zero page with the Kernal one, and when it's done I change them back so that I can continue to use zero page in my programm. This sounds cheap but I guess that would work.
Does anyone how well this fastloader works ? It seems like very doccumented and I like that. (btw I've got Metal Warrior's fasloader working in Vice playing with the options randomly)
About the first 2 bytes : I trought SEQ files did not have a loading adress but start immediately with data. Then what is the difference between SEQ and PRG ? |
| |
AlexC
Registered: Jan 2008 Posts: 299 |
I don't think that swapping in and out content of zero page is the right solution. As for safe memory area it all depends what you will need: location and size of address space + size and starting address of your code. Using kernel routines you can safely switch out BASIC and additionally use memory staring from C000 (you can use it even with BASIC still on). If you really need all the memory you can consider switching int/out D000 I/O area - I believe this has been described in one of C=Hacking issues. Additionally you can use lower parts of stack - assuming you will not use a lot of subroutines (JSR) and you are not using some decrunching routine. You can also use $02A7-$02FF (often used by simple autostart code) area and $033C-$03FB (tape buffer).
I'm not sure about what vectors are you talking about but all starting from $300 are very well documented. Take a look at this document:
http://unusedino.de/ec64/technical/aay/c64/zpmain.htm
As for CovertBitOps loader it has few drawbacks if I remember correctly - one is that it will crash during NMI. |
| |
Bregalad Account closed
Registered: Jul 2008 Posts: 42 |
Thanks for pointing to some more Kernal doccumentation, I found the official documentation to be quite lacking about which variables are used.
I'm going to write video games so definitely Basic won't be used at all, and I guess I will make very minor use of the Kernal as well.
I don't want to start a new thread just for that, but I canot found a list of all sources of interrupts. What I know so far :
- Raster IRQ interrupt (use on scanline #0 for VBlank, other scanlines for rester effects ?)
- Timer IRQ (poorly doccumented at first glance, most things I see arround just mention to disable it before using Raster IRQ)
- Other devices that directly connects to C64's bus can probably do IRQs as well (cartridges, serial port)
- Run/Stop+Restore NMI (it this correct ?)
I can't find a Reset button on my C64 so I don't know if there is any Rest interrupt source other than turning off then on, but Vice has a soft reset option...
As long as the loader runs with Kernal disabled I can set my own NMI vector at $fffa, and make it do whanever I want to not freeze the loading (this may also be possible with the secondary software vector if Kernal is enabled). |
| |
Oswald
Registered: Apr 2002 Posts: 5094 |
fffe-ffff: cia #x generated irqs, VICII generated irqs, brk
fffa-fffb: cia #y generated irqs, restore key,
(fffc-fffd: reset ?:) |
| |
AlexC
Registered: Jan 2008 Posts: 299 |
Quote: Thanks for pointing to some more Kernal doccumentation, I found the official documentation to be quite lacking about which variables are used.
I'm going to write video games so definitely Basic won't be used at all, and I guess I will make very minor use of the Kernal as well.
I don't want to start a new thread just for that, but I canot found a list of all sources of interrupts. What I know so far :
- Raster IRQ interrupt (use on scanline #0 for VBlank, other scanlines for rester effects ?)
- Timer IRQ (poorly doccumented at first glance, most things I see arround just mention to disable it before using Raster IRQ)
- Other devices that directly connects to C64's bus can probably do IRQs as well (cartridges, serial port)
- Run/Stop+Restore NMI (it this correct ?)
I can't find a Reset button on my C64 so I don't know if there is any Rest interrupt source other than turning off then on, but Vice has a soft reset option...
As long as the loader runs with Kernal disabled I can set my own NMI vector at $fffa, and make it do whanever I want to not freeze the loading (this may also be possible with the secondary software vector if Kernal is enabled).
Talking about loaders and interrupts keep in mind that fastloading is cycle exact so any uncontrolled interrupt trigger can in fact ruin whole loading process. Even if you setup your own IRQ and NMI handlers you will still loose cycles due to interupt request and RTI. This is why disabling NMI is better option. You can use CIA timers to better handle IRQ and NMI (including disabling NMI despite it's name). For the same reason some loaders also disable screen ($D011).
|
| |
Bregalad Account closed
Registered: Jul 2008 Posts: 42 |
I've got the loader I liked above working, and it's not cycle exact, even if it's probably by far not the fastest in the world they say it's completely synchronous and you can interupt it to play music and do graphical effects wile loading, which is way better. Even if the loading is slower, it's possible to hide it to the end user. I'll look forward to find a way to "disable" NMI, I remember seeing that on the codebase wiki.
By the way what are you supposed to do when you get an error ? I guess print a message telling the user to insert the disk correctly or something like that, and to press a key to try again ? |
| |
Oswald
Registered: Apr 2002 Posts: 5094 |
Quote: Talking about loaders and interrupts keep in mind that fastloading is cycle exact so any uncontrolled interrupt trigger can in fact ruin whole loading process. Even if you setup your own IRQ and NMI handlers you will still loose cycles due to interupt request and RTI. This is why disabling NMI is better option. You can use CIA timers to better handle IRQ and NMI (including disabling NMI despite it's name). For the same reason some loaders also disable screen ($D011).
this depends on the loader. 'modern' loaders do always a handshake before data gets sent through, so no irq/sprites/whatsoever disturbs them.
edit: to disable nmi, simply point fffa/b to an rti, or the harder way: initiate an nmi interrupt and never ack it. disabling nmi's is not crucial imho. I never do it. if one presses restore then its his own fault :) |