• Please review our updated Terms and Rules here

Hooking a device driver into the KERNAL

KC9UDX

KC9UDX

Space Commander
Joined
Jan 27, 2014
Messages
7,468
Location
Lutenblag
At some point I had read instructions on how to hook a new device driver into an existing KERNAL. I scoured my book collection and can find no information on this. So it may have been in a magazine that I no longer have, or maybe even on some early website. If someone knows where to find this, I would greatly appreciate the information.

What I'd like to do is create a new hardware mass storage solution that I can attach to the Commodore 64 expansion port. I'd like it to appear as a standard device. So if this device is at address 11, one could
LDA #1
LDX #11
LDY #2
JSR SETLFS
Thus of course, LOAD"TEST",11 in BASIC work as well.

Every piece of advise I've seen so far is that a custom KERNAL would need to be written. If so, that's what I'll have to do. But it seems to me that this shouldn't need to be done. Of course, finding and reading again a KERNAL disassembly would allow me to figure this out on my own. But I expect that there are some here who already know how to do this.
 
ClassicHasClass said:
Why not just change the Kernal vectors in RAM to point to your routines? They can just call the original routines if it's not a device they care about.
Click to expand...

That's an option I've considered. But I thought there was an official, or at least unofficial but common way to add a hook. That way I only have to handle the device I/O, without the logical file layer. If I'm going to intercept and handle standard KERNAL functions, I might as well go the whole route and build a complete semi-custom KERNAL, something I prefer not to do at this point. Because if I do, I'm going to go full bore and replace BASIC and not really have a compatible machine anymore.
 
Changing the RAM vectors is an option but that means you have to load a program that does the change. And that means you have to load it from a device the C64 knows and that cannot be the device KC9UDX wants to attach.

In 1986 I attached a XT clone with its LPT port to the userport so it could act as an HDD for my C64. I first used the method I mentioned above but then I changed the Kernal in time. I just looked for the routines where the device number was checked. When the Kernal had decided that it was dealing with an IEC device, I interrupted the routine with a JMP and checked if device 12 was addressed. If not, my routine returned to the original Kernal Routine. If it was, my own routine handled the rest. In this case I removed the RS232 routines to create some room for my routines.

Regarding the source codes, please have a look here.
 
Another way would be to put your code into a ROM at the expansion port or cartridge port (depending on which Commodore you are working with). On the Vic-20 for example, you have IO23 which gives you 2KiB to work with.
 
Ruud said:
Changing the RAM vectors is an option but that means you have to load a program that does the change. And that means you have to load it from a device the C64 knows and that cannot be the device KC9UDX wants to attach.

In 1986 I attached a XT clone with its LPT port to the userport so it could act as an HDD for my C64. I first used the method I mentioned above but then I changed the Kernal in time. I just looked for the routines where the device number was checked. When the Kernal had decided that it was dealing with an IEC device, I interrupted the routine with a JMP and checked if device 12 was addressed. If not, my routine returned to the original Kernal Routine. If it was, my own routine handled the rest. In this case I removed the RS232 routines to create some room for my routines.

Regarding the source codes, please have a look here.
Click to expand...

Thanks Ruud! I haven't had a chance yet but I suspect you have precisely what I'm looking for.

(I'm on vacation now: currently spending my vacation at a laundromat recovering from a flash flood!)
 
You must log in or register to reply here.
Back
Top