unused I/O location for debug purposes
Moderator: Moderators
unused I/O location for debug purposes
i have recently started with (finally!) adding some kind of automatic testing to VICE starting with the c64 emulators... and would of course like to do the same for vic20 too (if only to kick tlr out of his sleep period =))
what i am looking for is an "unused" I/O location in the vic20 memory map...
- it must not conflict with any of the vic20s regular chips (obviously). it may however be implemented as an overlay to a register that has no significant side effects when written to (see c64 note(*))
- it must not change with the different vic20 configurations/memory maps
- ideally it does not conflict with any "common" expansion
- a bonus would be if the write to that location can be "seen" also at the expansion port. this isnt strictly necessary, but would be nice just in case someone would ever knock up such debug mechanism in a real cartridge.
(*) c64 note: for the C64 we have picked $d7ff - this is normally a mirror of the SID register $1f, which is unused.
if somehow who is more into the vic20 than me could give some suggestions, that would be great
what i am looking for is an "unused" I/O location in the vic20 memory map...
- it must not conflict with any of the vic20s regular chips (obviously). it may however be implemented as an overlay to a register that has no significant side effects when written to (see c64 note(*))
- it must not change with the different vic20 configurations/memory maps
- ideally it does not conflict with any "common" expansion
- a bonus would be if the write to that location can be "seen" also at the expansion port. this isnt strictly necessary, but would be nice just in case someone would ever knock up such debug mechanism in a real cartridge.
(*) c64 note: for the C64 we have picked $d7ff - this is normally a mirror of the SID register $1f, which is unused.
if somehow who is more into the vic20 than me could give some suggestions, that would be great
I'm just a Software Guy who has no Idea how the Hardware works. Don't listen to me.
- Mike
- Herr VC
- Posts: 4816
- Joined: Wed Dec 01, 2004 1:57 pm
- Location: Munich, Germany
- Occupation: electrical engineer
Re: unused I/O location for debug purposes
Such a register could be put into I/O 0 ($9000..$93FF). There exist some "holes", where neither VIC nor VIA #1 or VIA #2 are selected. Specifically: VIC selects on all CPU addresses that match %10010000xxxxxxxx, VIA #1 selects on all CPU addresses that match %100100xxxxx1xxxx and VIA #2 selects on all CPU addresses that match %100100xxxx1xxxxx. *)
The resulting holes then are of the type: %10010001xx00xxxx, %10010010xx00xxxx or %10010011xx00xxxx. Normally, CPU reads on these addresses return the last byte VIC fetched over the BD bus (due to parasitic capacitances). **) So, one possible location, that would fit all your criteria (except the last), then would be %1001001111001111 = $93CF. I/O 0 does not appear on the cartridge port, though.
However, if that debug functionality is supposed to be possibly supported by a cartridge, that cartridge would be a legit user of the I/O 2 ($9800..$9BFF) or I/O 3 ($9C00..$9FFF) address range anyhow. ***) Just a matter of conditional assembly.
*) Yes, this allows for addresses where two of them or all three are selected. Funny results guaranteed.
**) at least one test program of tlr relies on this behaviour (at another address than $93CF) and I also use this to check for the presence of VIC-accessible RAM at $0400..$0FFF (see my VFLI mod).
***) the remaining 1K of the I/O range ($9000..$9FFF) of course is allocated to the colour RAM at $9400..$97FF (I/O 1).
The resulting holes then are of the type: %10010001xx00xxxx, %10010010xx00xxxx or %10010011xx00xxxx. Normally, CPU reads on these addresses return the last byte VIC fetched over the BD bus (due to parasitic capacitances). **) So, one possible location, that would fit all your criteria (except the last), then would be %1001001111001111 = $93CF. I/O 0 does not appear on the cartridge port, though.
However, if that debug functionality is supposed to be possibly supported by a cartridge, that cartridge would be a legit user of the I/O 2 ($9800..$9BFF) or I/O 3 ($9C00..$9FFF) address range anyhow. ***) Just a matter of conditional assembly.
*) Yes, this allows for addresses where two of them or all three are selected. Funny results guaranteed.
**) at least one test program of tlr relies on this behaviour (at another address than $93CF) and I also use this to check for the presence of VIC-accessible RAM at $0400..$0FFF (see my VFLI mod).
***) the remaining 1K of the I/O range ($9000..$9FFF) of course is allocated to the colour RAM at $9400..$97FF (I/O 1).
Re: unused I/O location for debug purposes
well, the major reason for asking is that the precompiled test programs should "just work" - recompiling them for certain tests is always annoying (and ultimatively keeps people from doing it)Just a matter of conditional assembly.
I'm just a Software Guy who has no Idea how the Hardware works. Don't listen to me.
- Mike
- Herr VC
- Posts: 4816
- Joined: Wed Dec 01, 2004 1:57 pm
- Location: Munich, Germany
- Occupation: electrical engineer
Re: unused I/O location for debug purposes
If the possible realisation as debug cartridge is as important as you wrote, any address in I/O 2 or I/O 3 is at the disposal of the cartridge and its firmware. Of course, recent attempts here at Denial to use that scarce resource for other purposes than for cartridge control registers only serve to lure people onto the way to the Dark Side™.
P.S. some older programs are too eager in initialising the colour RAM and thrash part of I/O 2. For that reason, newer cartridges mostly use registers in I/O 3 for their purposes.
P.S. some older programs are too eager in initialising the colour RAM and thrash part of I/O 2. For that reason, newer cartridges mostly use registers in I/O 3 for their purposes.
Re: unused I/O location for debug purposes
An alternative might be to use the last 6 bytes of the color ram? The screen only requires 506 bytes for its color so the last 6 bytes are usually unused. I understand that it would interfere with anything that actually used it.. but maybe its good enough?
- Mike
- Herr VC
- Posts: 4816
- Joined: Wed Dec 01, 2004 1:57 pm
- Location: Munich, Germany
- Occupation: electrical engineer
Re: unused I/O location for debug purposes
Like, for example, my TI$ border clock ...Kakemoms wrote:I understand that it would interfere with anything that actually used it [...]
Re: unused I/O location for debug purposes
Yea, I also made a mouse driver that showed x&y in those 6 bytes.. but it is poor looking unless you switch off the last 16 bytes on that line (which is a waste of cpu time).Mike wrote:Like, for example, my TI$ border clock ...Kakemoms wrote:I understand that it would interfere with anything that actually used it [...]
And there is no other row*col choice that fills up those 6 bytes either (except 16*32 which is too big anyway).
- Mike
- Herr VC
- Posts: 4816
- Joined: Wed Dec 01, 2004 1:57 pm
- Location: Munich, Germany
- Occupation: electrical engineer
Re: unused I/O location for debug purposes
On an unexpanded VIC-20, you can make that 'junk' (which actually is the beginning of the character ROM) disappear by clearing the colour RAM with:
However, as if one or two counter-examples weren't enough: you know there are 1K nibbles of colour RAM available, from $9400 to $97FF. It is possible to use a good amount of that colour RAM for an overscan screen. There are also some programs, which use left-over, non-displayed colour RAM to store other information.
You just can't count on that any byte of that address range might be unused.
Code: Select all
FORT=0TO15:POKE37888+T,1:NEXT
You just can't count on that any byte of that address range might be unused.
Re: unused I/O location for debug purposes
Writes to ROM does nothing on the vic20. Maybe $d7ff or similar can be used here too?
There might be some expansion that triggers on that though. CHARROM might be safest, which is $8000-$8fff.
There might be some expansion that triggers on that though. CHARROM might be safest, which is $8000-$8fff.
- Mike
- Herr VC
- Posts: 4816
- Joined: Wed Dec 01, 2004 1:57 pm
- Location: Munich, Germany
- Occupation: electrical engineer
Re: unused I/O location for debug purposes
On real HW, 'writing' to ROM (regardless of character, BASIC or KERNAL) will at least lead to a bus conflict, i.e. the drivers of CPU or the data bus '245 working against the drivers of the ROMs.
It is still not clear to me what kind of debug procedure that address (or maybe even a couple of those addresses?) is supposed to support. If I am right in my assumption, that this is foremost an in-VICE support *and* only writes to that register are significant, then of course either a ROM address or one of the aforementioned "holes" in the I/O space could be used; VICE could implement this similar to KERNAL traps. Reads of those "holes" are much more problematic, as then the "functionality" of residual bus data wouldn't work anymore for those addresses (and reads of ROM o/c return the ROM contents).
But you can't have the cake and eat it: if the debug register optionally should also exist in a cartridge, and on real hardware, ROM and "I/O 0" accesses aren't decoded properly for the expansion port - only the low 14 address bits are visible and there are no external select signals available. I/O 2 or I/O 3 could be used for this - the cartridge's firmware being a legit user of that address range -, however there will then be conflicts if that debug procedure is expected to co-exist with any cartridge.
An even more complex solution might involve a modded VIC-20, which *internally* decodes some addresses of the aforementioned "holes" in I/O 0, or ROM (and, once again, writes only!) for that debug register, mirroring what is done in VICE to implement the debug functionality.
It is still not clear to me what kind of debug procedure that address (or maybe even a couple of those addresses?) is supposed to support. If I am right in my assumption, that this is foremost an in-VICE support *and* only writes to that register are significant, then of course either a ROM address or one of the aforementioned "holes" in the I/O space could be used; VICE could implement this similar to KERNAL traps. Reads of those "holes" are much more problematic, as then the "functionality" of residual bus data wouldn't work anymore for those addresses (and reads of ROM o/c return the ROM contents).
But you can't have the cake and eat it: if the debug register optionally should also exist in a cartridge, and on real hardware, ROM and "I/O 0" accesses aren't decoded properly for the expansion port - only the low 14 address bits are visible and there are no external select signals available. I/O 2 or I/O 3 could be used for this - the cartridge's firmware being a legit user of that address range -, however there will then be conflicts if that debug procedure is expected to co-exist with any cartridge.
An even more complex solution might involve a modded VIC-20, which *internally* decodes some addresses of the aforementioned "holes" in I/O 0, or ROM (and, once again, writes only!) for that debug register, mirroring what is done in VICE to implement the debug functionality.
Re: unused I/O location for debug purposes
Good point. The kernal actually does this itself though. The routine at $fd52 writes to $fd6d, which later became the infamous $fd15/$fd30 bug on the c64.Mike wrote:On real HW, 'writing' to ROM (regardless of character, BASIC or KERNAL) will at least lead to a bus conflict, i.e. the drivers of CPU or the data bus '245 working against the drivers of the ROMs.
- Mike
- Herr VC
- Posts: 4816
- Joined: Wed Dec 01, 2004 1:57 pm
- Location: Munich, Germany
- Occupation: electrical engineer
Re: unused I/O location for debug purposes
$FD52 is only ever called to restore the KERNAL vectors to their default values. Thus, in that case, both CPU and ROM put the same logic levels on the data bus (on the C64 o/c "write-through" to RAM happens). So, no harm done.
$FD57 (or, more evidently, $FF8D) could be used with C=1 to read off the current contents of $0314 et seqq. and write them to another place. Supplying $FD6D as target address to store away possibly different values at $0314 would constitute a programming error, IMO.
In case of different logic levels (also with stray writes to ROM), all involved chips are either NMOS or TTL. The internal pull-ups on the conflicting signals will limit the sink current, and the result will still be a logic 0 in most cases.
$FD57 (or, more evidently, $FF8D) could be used with C=1 to read off the current contents of $0314 et seqq. and write them to another place. Supplying $FD6D as target address to store away possibly different values at $0314 would constitute a programming error, IMO.
In case of different logic levels (also with stray writes to ROM), all involved chips are either NMOS or TTL. The internal pull-ups on the conflicting signals will limit the sink current, and the result will still be a logic 0 in most cases.
Re: unused I/O location for debug purposes
Good point too.Mike wrote:$FD52 is only ever called to restore the KERNAL vectors to their default values. Thus, in that case, both CPU and ROM put the same logic levels on the data bus (on the C64 o/c "write-through" to RAM happens). So, no harm done.
This, combined with the purpose of automated emulator testing makes it a viable choice IMO. There could be better alternatives though.Mike wrote:In case of different logic levels (also with stray writes to ROM), all involved chips are either NMOS or TTL. The internal pull-ups on the conflicting signals will limit the sink current, and the result will still be a logic 0 in most cases.
Re: unused I/O location for debug purposes
one write-only register, when anything is written to it the emulator quits with the written value as exit code. (an actual debug cartridge could keep that value in a register for later examination, or send it to a remote host by whatever means)It is still not clear to me what kind of debug procedure that address (or maybe even a couple of those addresses?) is supposed to support.
it should also be "real" I/O, because that makes hooking it up easier and more consistent across the emulators.
I'm just a Software Guy who has no Idea how the Hardware works. Don't listen to me.