Topic: C64 Test Code

Hoi!

as some of you may know i am somewhat active in the VICE team, and have written a bunch of test programs for it... which may or may not be useful to test FPGA based implementations as well :) (i am also using them to debug the chameleon core, and certainly found a bunch of awkward bugs by that) you can find the repository at sourceforge here: https://sourceforge.net/p/vice-emu/code … testprogs/

what i am looking for is not only programmers who perhaps can supply some more of such programs, but also suggestions on what else can and/or should be tested that currently is not. i think generally the coverage is quite good now, but there are always certain (border) cases left that are still untested. (and you would'nt believe how much software relies on strange border cases)

another thing i am looking at (not even started...) is making it possible to run these tests automatically, perhaps in some kind of infrastructure that may also allow to use them with ISIM or whatever - but i didnt find a good way to generate proper bus activity references etc pp, i am open for suggestions there :) maybe the needed data can be generated by VICE? i dont know :)

Re: C64 Test Code

Sounds very good! Will have a look!

What I am missing are test cases I can actually use together with HW with proper documentation what they do and what they expect as response (eg. asserts). I tried some diagnosis tools where some tests fail, w/o details info what failed - it will be hard to use it at all (as you need a specific debug setup at proper positions in HW to track the issue). Eg. in one of the CBM diagnosis modules it mentiones a "IRQ fail", on the Replay core, I have no clue what this means and how to debug it, and IRQ work work fine in another diag. module...

Automatic tests could be handled by the ARM, in w.c. by using a special FW for it. But again, the difficulty will be how/what to trace back, as this will require probably some HW signals to look at or so. Alternatively only memory snapshots from the core could be compared w/o additional effort... (at not very accurate time points w/o adding some good handshaking)

/WoS

Re: C64 Test Code

yes, proper description has been a problem with the vice tests too... however, often the programs are so simple, a quick look at the source should give away wth it is doing (the "ciavarious" and "viavarious" tests are a good example... writing descriptions for them is kindof useless, they dont do "useful" stuff, and they are trivial :=))

Re: C64 Test Code

Sorry, but how hard can it be to have at least one comment line at the begin of the program to tell what it does? I don't speak about a 10 page article for each and every program. Independent of program complexity, this is something every serious programmer does automatically, because it is trivial to do as well and required by any proper coding guideline I know.

It is simply waste of time to read through sources of others just to get out what they do, especially when I am looking for a specific test for an actual HW problem to fix (and not setting up a regression test). At the end I save my time and just start coding the test myself, especially if it is a simple one, before spending my time to browse through several files to check what it does (and even worse when figuring out it is -hopefully not- useless stuff as you mention wink )

/WoS

5 (edited by gpz 2014-06-14 01:38:56)

Re: C64 Test Code

Sorry, but how hard can it be to have at least one comment line at the begin of the program to tell what it does? I don't speak about a 10 page article for each and every program. Independent of program complexity, this is something every serious programmer does automatically, because it is trivial to do as well and required by any proper coding guideline I know.

well :) generally i agree, and often when i touch those programs, i add either a readme (which i prefer) or some comments into the code... in many cases the lack of comments is simply heritage from the dark ages =)

however, when the code is something like

ldx #0
stx $dc04
loop:
lda $dc04
sta result,x
inx
bne loop

(this is basically what the ciavarious tests do in a bunch of variations) then IMHO a one line comment ("cycle exact timer A latch and count test") isnt really useful at all - you'll have to read the code anyways, or give a rather lengthy description on what exactly happens (in every single cycle) or the description will be rather useless. And well, for anyone who tries to implement a cycle exact CIA, it shouldnt take longer to understand that code than reading the respective description =P

It is simply waste of time to read through sources of others just to get out what they do, especially when I am looking for a specific test for an actual HW problem to fix (and not setting up a regression test). At the end I save my time and just start coding the test myself, especially if it is a simple one, before spending my time to browse through several files to check what it does (and even worse when figuring out it is -hopefully not- useless stuff as you mention  )

thats a different problem imho (picking a test for some specific problem you have) - personally i find reading through individual readmes or sourcecodes equally annoying... which is why i also started adding readmes to individual directories that explain briefly what each program does.

bottom line is: sure, ideally there should be comments and readmes - however in the past people were often too lazy to write test programs, let alone comment them properly :) recently written ones should be commented and described (see eg here) as you say... and the older stuff is being updated slowly, mostly when some of the tests fail for me and i have to explain the problem to peter :=)

so i guess that you can add "people writing comments and readmes" to the above mentioned list of what i am looking for, even if i dont really expect to find them here =)

edit: coming back to your first post, i find those old diagnostic cartridges and programs from cbm pretty useless myself as well ... eg there is some "burn in" test for the CBM-II which fails in VICE ("CIA BAD!") and even after several hours disassembling i have no clue wth the problem is exactly.