• Please review our updated Terms and Rules here
  • Exhibitor application for VCF West 2022 is now open! If you are interested in exhibiting, please fill out the form here.
  • Here are the results of the VCF East 2022 Post Event Survey: Survey Results

PET/C64 et-al development with CC65

Megatron-uk

Experienced Member
Joined
Oct 3, 2011
Messages
122
Location
Durham, Durham, United Kingdom
Hey there,

I picked up a very clean PET 2001N-32 a couple of weeks ago from an electronics disposal (it was bound for the trash!)... And it has turned out to be perfectly working.

Anyway, I thought I'd had a go writing something for it, so have turned to CC65 which is working reasonably well (testing so far on VICE as I'm lacking any tape, disk or sd card reader yet).

I have a main binary/prg running, linked from several objects and pet.lib... one thing I'm trying to do is limit memory use by storing long strings, data etc in external files and loading only when needed... So I've had to turn to the cbm_k_* functions (which I think I am starting to get my head around - though I've not successfully managed to read any data yet!).

Anyway, my main question is how to define the device you open using cbm_k_setlfs... In VICE the d64 image I have my compiled app.prg on is loaded at 8,1... But if my application runs from somewhere else, how can I know where it is running from and adjust the device and drive numbers to suit the location of where the accompanying datafiles are? Hardcoding device numbers feels wrong.

Are there any kernal calls or CC65 wrappers to return the equivalent of 'current device number'?
 

ClassicHasClass

Veteran Member
Joined
Mar 22, 2013
Messages
1,572
Location
Sunny So Cal
If memory serves, a PEEK(212) on the PET will get you the last device number, so if it was loaded from that device, that should be in that location (analogous to PEEK(186) on a C64).
 

Megatron-uk

Experienced Member
Joined
Oct 3, 2011
Messages
122
Location
Durham, Durham, United Kingdom
Thanks - that seems to do something.

According to the PET memory map, the location 0xD4 / 212 does hold current file device number.. but at least within VICE, it doesn't appear to represent the device number that my .prg is running from when first examined.

My file handling routine looks like this:

Code:
unsigned char open_file(unsigned char filehandle, char *filename){
// Opens a datafile on the current disk device, ready for it to be read
unsigned char dev = 0;
unsigned char sa = 0;

dev = current_device();

cprintf("\r\nbefore dev: .%d.", dev);

// Set device operation, device number and drive number
//cbm_k_setlfs(filehandle, current_device(), current_sub_device());
cbm_k_setlfs(filehandle, 8, 0);
if (cbm_k_readst()){
   cputsxy(screen.error_x, screen.error_y, STRING_DEVICE_NOT_FOUND);
   return ERROR_DATAFILE;
}

// Set name of the file
cbm_k_setnam(filename);
if (cbm_k_readst()){
   cputsxy(screen.error_x, screen.error_y, STRING_FILENAME_ERROR);
   return ERROR_DATAFILE;
}

// Open file
cbm_k_open();
if (cbm_k_readst()){
   cputsxy(screen.error_x, screen.error_y, STRING_FILE_NOT_FOUND);
   return ERROR_DATAFILE;
}

// Assign a file handle number
cbm_k_chkin(filehandle);
if (cbm_k_readst()){
   cputsxy(screen.error_x, screen.error_y, STRING_FILEHANDLE_ERROR);
   return ERROR_DATAFILE;
}

dev = current_device();
cprintf("\r\nafter dev: .%d.", dev);

// No errors, file opened
return ERROR_NONE;
}

... where current_device() is a PEEK to 0xD4 / memory location 212, and this is the output of the before-the-file-handler-is-called, and afterwards:

Click image for larger version  Name:	vice_get_current_device.png Views:	0 Size:	29.4 KB ID:	1235220 vice_loading.png

For some reason, the device number is set to 3, before I try opening my datafile, but the second PEEK immediately afterwards shows that the correct device number 8 has been set. VICE is definitely loading the .prg from a d64 disk allocated to device 8, as you can see.
 
Last edited:

Megatron-uk

Experienced Member
Joined
Oct 3, 2011
Messages
122
Location
Durham, Durham, United Kingdom
So it appears that the CC65 runtime does something with the screen device (device 3) before I get control in main().

If I put a PEEK(212) as the very first line in my main() before I do even a single printf/cprint/clear/text/graphics mode command, I still get device 3 as the last device opened. I do wonder if crt.o does something before I can even run anything?

In either case, it looks like the option to automatically determine the current storage device that my code is running from can't make use of the that memory address to do it without any user input; I may have to just have a horrible 'Please press the number of your drive' prompt at start :(
 

ClassicHasClass

Veteran Member
Joined
Mar 22, 2013
Messages
1,572
Location
Sunny So Cal
This might be where you have a little stub that saves the value in the location somewhere else and then calls your C code. Unfortunately that means an extra linking step.
 
Top