Question about Kernal function GETIN $FFE4
Moderator: Moderators
Question about Kernal function GETIN $FFE4
According to the PRG registers affected by this are A and X.
I seem to be getting corruption of Y register after calling this.
Is the PRG incorrect?
I seem to be getting corruption of Y register after calling this.
Is the PRG incorrect?
yes!Kananga wrote:I'd always assume that kernel functions use all registers. There are not many registers in a 6502 anyway.
You could have a look into the ROM listing or step into the routine using a debugger to see what's happening.
In case of GETIN function:
If GETIN uses keyboard:
- if no key pressed (empty key buffer) only AC ist used
- if key in buffer, all registers are lost
If other sources (IEC) register are lost.
Most kernel functions will most likely use all registers, it's which ones are preserved by the function and restored on return (other than those which are used to return values)Kananga wrote:I'd always assume that kernel functions use all registers. There are not many registers in a 6502 anyway.
You could have a look into the ROM listing or step into the routine using a debugger to see what's happening.
CHROUT $FFD2 affects none for example, otherwise a print loop would involve some form of --> TXA/TYA PHA before and PLA TAY/TAX afterwards.
It's not a big problem as I'll just push it on the stack, was just wondering if this is incorrect - and how many other errors might be in the book.
So the PRG is incorrect then.Diddl wrote:yes!Kananga wrote:I'd always assume that kernel functions use all registers. There are not many registers in a 6502 anyway.
You could have a look into the ROM listing or step into the routine using a debugger to see what's happening.
In case of GETIN function:
If GETIN uses keyboard:
- if no key pressed (empty key buffer) only AC ist used
- if key in buffer, all registers are lost
If other sources (IEC) register are lost.
Thanks for all replies
I have an annotated memory map layout which includes the names of the ROM routine entry points, but doesn't include comments about their register dependencies and usage - if you have that, do you feel like sharing? I'll post my VICMap file in exchange...Kananga wrote:That's why I always have a commented ROM listing on my desk when programming for the VIC.KingTrode wrote: So the PRG is incorrect then.
Is your map the one found on funet/zimmers?FD22 wrote: I have an annotated memory map layout which includes the names of the ROM routine entry points, but doesn't include comments about their register dependencies and usage - if you have that, do you feel like sharing? I'll post my VICMap file in exchange...
The commented ROM listing I have is in the German book "VC-20 Intern" (published by Data Becker, 1983). I don't know if anybody scanned it already and it is in German, of course.
Buy the new Bug-Wizard, the first 100 bugs are free!
Nope - well, not exactly, it's obviously the VIC memory map, but I've annotated every writeable memory location and named every ROM routine (using either the commonly-accepted name, or a representative one of my own making if there didn't seem to be one).
Does anyone have a link to an annotated / commented ROM disassembly?
Does anyone have a link to an annotated / commented ROM disassembly?
I just found this in The Complete Commodore Inner Space Anthology (ftp.zimmers.net/pub/cbm/manuals/anthology/index.html):
GETIN FFE4 "Get character from current input device"
output: .A .. data .X .. alt. .Y alt.
(Machine Language Section: BASIC 2.0/4.0 Kernal Routines, VIC 20/Commodore 64 Kernal Routines)
Not a ROM listing, but it looks like a useful reference.
GETIN FFE4 "Get character from current input device"
output: .A .. data .X .. alt. .Y alt.
(Machine Language Section: BASIC 2.0/4.0 Kernal Routines, VIC 20/Commodore 64 Kernal Routines)
Not a ROM listing, but it looks like a useful reference.
Buy the new Bug-Wizard, the first 100 bugs are free!
Sounds like your map is more comprehensive than the one I use for my debugger (http://vic20emu.googlecode.com/svn/trun ... vicrom.sym) (It's the one from zimmers.net)FD22 wrote:Nope - well, not exactly, it's obviously the VIC memory map, but I've annotated every writeable memory location and named every ROM routine (using either the commonly-accepted name, or a representative one of my own making if there didn't seem to be one).
Would you like to share your map?
Buy the new Bug-Wizard, the first 100 bugs are free!
Here is a link to my VICMap file, which is designed to be used as an 'include' for DASM-based VIC Assembler projects (which is what I created it for). You can rename it as '.asm' if you're using that as your Assembler extension - I already have that associated with an x86 dev-tool, so I use .6502 to map DASM source files to a different toolchain.
Here it is: http://vicdev.googlecode.com/files/VICMap.6502
Here it is: http://vicdev.googlecode.com/files/VICMap.6502
If I minded anyone using it, or a derivative of it, I wouldn't have posted it.
I've gleaned an immense amount of VIC-related information from this forum and other internet resources, so I consider posting stuff like VICMap a fair return for all the knowledge now in my head that other peoples' work has contributed to.
I've gleaned an immense amount of VIC-related information from this forum and other internet resources, so I consider posting stuff like VICMap a fair return for all the knowledge now in my head that other peoples' work has contributed to.