BASlist Java Tool to list BASIC files

[arnoldemu]

Attached is a dsk with a BASIC program (2 copies slightly different)

Both have crazy characters in REM and PRINT statements.

So my question is, how should these characters be listed? The PC characters are not the same as the CPCs, so we do not get a true representation.

Should it have a special form e.g. [CTRL+A]?

I can't remember what magazines did when these listings were printed.

[copychr$]

This throws everybody into a tiff. Server too.
Can't even paste some of the output into a code window here.

An unbreakable cold-war secret code?
Time to fish out that pencil with the eraser ...

[Gryzor]

YOU BORKED THE SERVER! Damn you...

[AMSDOS]

I once saw a type-in which I think was in our Aussie Mag "The Amstrad User", which had CTRL+X in it, and of course when the program was first published the control codes came out as an "X", which was corrected in a later issue where someone had to draw in the top & bottom line, so I think the magazines would of had a bit of a battle trying to get the codes out correctly, I don't recall AA ever having programs with control in their type-ins, through when the AA Covertapes came out with Cheat-Modes, I remember some of those Graham Smith cheats having Control Codes in them, and I think this was discussed in one of those later issues after someone noticed it, to which it was discussed how they had their Advantages/Disadvantages. Normally I just stick with the good old CHR$() when using Control Codes which is the friendly way. 

[arnoldemu]

Attached is my latest exe.

Fixes:
* REM statements are now decoded correctly
* Floating point numbers are mostly displayed correctly (a few tweaks to needed concerning how numbers are rounded up/down for display)
* ON SQ fixed.

Please try it.

[copychr$]

Attached is my latest exe.

As expected; a new version comes along while one is off-line doing the dirty ;-)

Ripabug - a Dos utility - runs both versions of Baslist and tests their output.
Against each other and, if available, against the original ASCII version.

Everything is set-up to find BAS programs that don't BasList correctly.

Kevin's new Baslist slotted right in, and looks to be doing good.
[...]

Post modfied: zip removed.
Please pick up again on this subject in post #39: ripabug v2
*An updated version of ripabug can be downloaded from post #49: Ripabug updated 

[copychr$]

The attached spreadsheet shows the results from a run through of the acu collection.

84% of 285 bas files now show "no differences" between the two versions of baslist.
Still, one cannot be sure there are no problems. Both might return the same faulty output, even null.

Two bas files were not processed because of name problems: foot&tag.bas and shoot'em.bas
Java error log attached.

[Devilmarkus]

Found the reason why you got an error log.

But no idea how to avoid that.

The imported BAS program seems to be corrupted.

I made a workaround and the log will not be written.

Instead a message pops up showing the linenumber what caused the problem.

(Not compiled yet, because I'm actually hard working on a mod for Skyrim...)

[copychr$]

It is the only one so far with this behaviour.

As you see from the zip, the basename shoot'em gets carried forward and baslisted by baslist_kev.
Output from baslist_jav is a null file named shootem.

It is likely basename related and I'll experiment some more with strange names.
Also, I'm still using the first test version, due to some problems under dos, but will try again w. newer version.

[copychr$]

Wyrd is the word.

Take a well crammed 10-liner, say to merge some code.
RENUM 60000. Many of those nice long lines have now been truncated by up to 4 chars.
The missing code can not be accessed by shift+copy or edited.
The listing will print out truncated. When saved to ASCII, the code is bad and when saved back to BAS, it will not run.

But the re-nummed code will still run, and when given lower line numbers, the missing chars show up again.

So we have "legal" code, that lists as "illegal".

Both versions of baslist take the wide view here and actually add back the lost chars at the end of the lines.
Neat! But now the lines are too long. High line numbers + original code results in output that will not run on the CPC anymore.

So, there is a §22. Repair the lines but leave unusable code, or render as per listing equally unusable code?
Somebody better call Ghostbusters.

[arnoldemu]

Interesting.

The problem is that BASIC has a line limit length of 256 chars?
So it is truncating the lines for display.

Yes, baslist would add the chars back, because it doesn't have this limit.

I will add a note to the wiki.

[copychr$]

Looking at just what's what when breaking code lines, this baslist output showed up.
It was forced by my fooling around, not found in a real bas program.

That pseudo bas code and some comments could be useful for counting out things.

The contents of this post looked awful and are much better viewed in the text version.
Look at the column numbers & line breaks in the  text editor.

Do check the numbers, the tax fellow always does and he seems smart enough.

[copychr$]

Found the reason why you got an error log.
But no idea how to avoid that.
The imported BAS program seems to be corrupted.
...

After changing the name shoot'em.bas to shoot-em.bas, everything was normal for your Baslist.

DOS won't copy etc. file names like: foot&tag.bas. Changing to foot-tag.bas gives normal results there also.

I'll be looking for more like this.

[copychr$]

After running through many of the files at ftp://ftp.nvg.ntnu.no/pub/cpc/typeins/
not all that much new turned up.

Atm about 3/4 of the German databox dsk files fail to extract under cpcxfs.
So that leaves quite a few programs in there. In emulators there are no problems though.

A much more usable version of ripabug will be up shortly to run on your own archives.

In the meantime, this is what the cat drug in:

[copychr$]

A much improved version of ripabug.

Many inefficiencies removed and fewer files generated.
Not much left to do apart from checking Baslist function.

The remainder of post was outdated and has been removed.
* Please, read on to next post  #40 ...

[copychr$]

Java Baslist test #2 now used in ripabug.

Redirecting the dos window output to nul ;-) did the trick. sry Markus.
Closing the program properly and unlocking the output file, speeds things up very much, to the point it's hardly fun anymore ...
The error-log messages are visible now. Those 5 sort programs that fail each produce one.

The problem with "& and +" characters in file names is due to me not quoting pathnames.
That is not needed for the 8.3 dos and cpc name format. But in the batchfiles, DOS reads these chars as operators and stops all treatment of the file.

The " ' " char (shoot'em.bas) gives trouble with Java baslist.

These "foo&bar.bas" files remain stuck in the topfolder. As a work-around they will be renamed to foo&bar.bad (my bad) and also sent on with the exports for separate attention.

This all requires an update, as will be the case any time the Baslists change etc.

To distinguish between versions the naming scheme is by date using y.mm.dd format as in; ripabug_130729 for today.
A null text file in the top folder also has this information.
Best leave it for verification. Unless one eliminates any older versions, things get mixed up fast.

Post modfied; outdated (130729) zip removed.
* A download for the current version of ripabug - 130901 - is posted in: #49 Ripabug updated

[copychr$]

More verifications using ASCII text files:

Comparing output from both Baslist versions turns up about 15% of programs that fail to render exactly like the original.
The rest are provisionally accepted by ripabug.

In order to accept a file with certainty, a comparison is necessary with the original ASCII code.
The type-ins ACU collection from 1989 to '92 at ftp://ftp.nvg.ntnu.no/pub/cpc/typeins/ comprises 7 dsk files, for a total of 282 BAS files.
The sole comparison - as done in the *.fcb files - between Baslist outputs eliminates 43 BAS programs (15%).

Only after preparing ASCII files is it possible to see what falls between the cracks.
That is; find programs where Baslist outputs are identical but both not exact.

This procedure eliminates a further 16 BAS files (6%).
Total fails becomes then 59 files out of 282, or 21%.

These 16 programs, possibly of special interest, can be found in folder "rip_samefail.dsk" in the zip.
Documentation logs are in the top folder, with the output files in the rejected bin there.

File snakx.bas, from this lot, is particular. I have added a mode 2 listing from Arnold and a view of that text in Notepad++
Clearly a solid knock-out blow and a winner for the type-ins crowd ;-)
Actually the file becomes corrupted when converting to ascii on the CPC, and Baslist also gets garbadge in.

The other 43 programs are on 3 dsk files in folder "xfails".
These dsk files go into the top folder of ripabug and allow for a complete analysis of mostly known problems.

All 59 selected BAS programs have been given an ASCII copy (*.TXA) on dsk, so any results are 100% verifiable.
These files also make a handy test lot for new Baslist versions.

The remaining 223 programs, some 80%, are flawlessly processed by both versions of Baslist.
Very fuzzy that.

[copychr$]

Here is an unusual fail, in a well known program.
cpcpara.bas by Marco Viieth.

The program works:
[attachimg=1]

and saves to ascii normally.

Kevin's baslist produces output but then stops working.
Java baslist shows a log and has null output.


[attachimg=2]
A fragment "8240" can be seen in kevin's baslist, then every line corrupts.

[Devilmarkus]

I don't know, where you get your BAS files from, but your attached cpcpara.bas is incomplete.

[copychr$]

It is as downloaded and used since forever.
Let me check, if it's a bad file, I'll pull the post.

[Devilmarkus]

Edit: Your file is not incomplete, but your CPCPARA.BAS file is ASCII and has some crappy chars @ end?

Try these files:

[copychr$]

 

This is the ending of my ascii version from emulator:
[attachimg=1]

The listing is identical there.

I've got nothing else to compare to.
Maybe all my BAS files are crappy?

[Devilmarkus]

Well I downloaded your attached cpcpara.zip file and checked the file CPCPARA.BAS in it.

It had additional characters @ EOF.

I then downloaded the "original" CPCPara from Marco Vieth's website and put it onto a new DSK.

This should list fine...

[copychr$]

Yes, now everything is normal...
I hope it's just 1 bad file.
Come to think of it; this file originally transferred itself to my PC.
Some history.

[copychr$]

* Please read this post together with the next, #50, where the final update is found.

Thanks for helping me out there, Markus.
Old file, but a heads up because I was not using CPCxfs properly.
The switches are now in, but it seems the output was OK anyway.

Ripabug got a re-write. Again much improved ;-)
This was easily done, as the initial concept only needed to be turned inside out.

* edit; zip removed.

Each DSK now gets it's own self-named archive, without user intervention.
The command is: MRIP for multiple dsks.
For  a few other commands, see the Readme or type info at the z> prompt.

One can not rename the ripabug folder. That name is now referred to in code.
The folder itself is not modified any more and remains usable.
One can rename the Holding folder as needed though.

As an addition, all Bas and Ascii files found, are grouped for easy manipulation.
In folder bas, three sort folders hold accepted, provisional or rejected programs.

The same demo.dsk is included. Each file should sort into one of those three categories.
Other dsks with ASCII files are available from post #41, and I will make up a more interesting mix.