unused I/O location for debug purposes

Basic and Machine Language

Moderator: Moderators

Post Reply
groepaz
Vic 20 Scientist
Posts: 1180
Joined: Wed Aug 25, 2010 5:30 pm

unused I/O location for debug purposes

Post by groepaz »

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 :)
I'm just a Software Guy who has no Idea how the Hardware works. Don't listen to me.
User avatar
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

Post by Mike »

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. :lol:

**) 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).
groepaz
Vic 20 Scientist
Posts: 1180
Joined: Wed Aug 25, 2010 5:30 pm

Re: unused I/O location for debug purposes

Post by groepaz »

Just a matter of conditional assembly.
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)
I'm just a Software Guy who has no Idea how the Hardware works. Don't listen to me.
User avatar
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

Post by Mike »

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.
Kakemoms
Vic 20 Nerd
Posts: 740
Joined: Sun Feb 15, 2015 8:45 am

Re: unused I/O location for debug purposes

Post by Kakemoms »

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?
User avatar
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

Post by Mike »

Kakemoms wrote:I understand that it would interfere with anything that actually used it [...]
Like, for example, my TI$ border clock ...
Kakemoms
Vic 20 Nerd
Posts: 740
Joined: Sun Feb 15, 2015 8:45 am

Re: unused I/O location for debug purposes

Post by Kakemoms »

Mike wrote:
Kakemoms wrote:I understand that it would interfere with anything that actually used it [...]
Like, for example, my TI$ border clock ...
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).

And there is no other row*col choice that fills up those 6 bytes either (except 16*32 which is too big anyway).
User avatar
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

Post by Mike »

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:

Code: Select all

FORT=0TO15:POKE37888+T,1:NEXT
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.
tlr
Vic 20 Nerd
Posts: 567
Joined: Mon Oct 04, 2004 10:53 am

Re: unused I/O location for debug purposes

Post by tlr »

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.
User avatar
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

Post by Mike »

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.
tlr
Vic 20 Nerd
Posts: 567
Joined: Mon Oct 04, 2004 10:53 am

Re: unused I/O location for debug purposes

Post by tlr »

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.
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.
User avatar
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

Post by Mike »

$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.
tlr
Vic 20 Nerd
Posts: 567
Joined: Mon Oct 04, 2004 10:53 am

Re: unused I/O location for debug purposes

Post by tlr »

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.
Good point too.
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.
This, combined with the purpose of automated emulator testing makes it a viable choice IMO. There could be better alternatives though.
groepaz
Vic 20 Scientist
Posts: 1180
Joined: Wed Aug 25, 2010 5:30 pm

Re: unused I/O location for debug purposes

Post by groepaz »

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.
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 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.
Post Reply