Hi group. For the last month, a friend and I have worked on the FOCAL-65 source code a YouTube video subscriber sent me. We have "reconstructed" the Aresco version (V3D) that runs on a KIM-1 or clone/replica from a MOS TIM monitor-based listing by the Denver 6502 Group (distributed by 6502 Program Exchange back then). Plus, the original principal author, Wayne Wall, sent me the Apple II version (V4). All were non-editable PDFs or plain old TIFF pictures. We're done, as of last night, but we've both been so deep into this project that we likely can't even see our own errors anymore. We need fresh eyes.

What I'd like to do is assemble a team of 3-5 people interested in proofreading our reconstructed source code against the MOS TIM source for V3D. Once it's verified, I can publish the result in the usual places. Each proofreader could take a chunk (the whole thing is 5.6 KB). Anyone interested?

If you'd like to know more about this interesting high-level language, I have a video up about it: https://www.youtube.com/watch?v=uVrsQ2MRY-M

Best regards, Dave Hassler

Sign me up, Dave! And welcome to the forum.

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

yess sign me up for this....!!

How big of a "chunk" would proofers want? 512b? 1K? Something else?

If you're not wrestling with a hard deadline, why don't you just follow your initial instinct and see how it works out. If the allocations need to be adjusted, then so be it. Here's a recent example of me volunteering in a similar situation, with some light assistance from Rob.

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

That sounds fine to me, Mike, and no hard deadlines here....maybe by New Year's Day (??) I need one more volunteer and then I can pass out 1 KB parts.
Dave

Sign me up for 1KB then.

GREAT - Thanks, guys. I'll put the 1-kb parcels together and PM "The Gang of Five."
stand by...

Quick questions, Dave. Spaces or tabs? There seems to be a random mixture in the .txt file, and I'm fine with either, although my section seems to favor spaces. Go with the flow, right?

https://www.youtube.com/watch?v=SsoOG6ZeyUI

[P.S. Hey, fellas, watch out for those LDA# CMP# LDX# LDY# mnemonics, and make sure the # makes it over to the operand! I see those types of errors sprinkled all over!]

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

Yeah - go with what's there re: spaces/tabs. I guess it really won't matter at assembly time. And yeah, PLEASE check for those immediate mode mnemonics -- after so much typing, Nils and I just got a blit blurry at times!

Evening Gents

Gavin here, just checking in to say hello and confirm I've picked up my share of the "chunks". I shall embark on some judicious proof reading shortly

Gavin ..... aka Gav, aka TheElkulatorGuy

I've located my chunk - it took me a minute to figure out that the address ranges are for the NEW version of the software, as called out in FOCAL_MAIN_LISTING_work3.ASM, rather than the addresses in the original listing.

I've already located a potential issue with FSUB, which appears to subtract two floating point numbers. Looking at the code, it appears that subtract is implemented by adding the complement, which makes sense to me. The issue is that there is a comment indicating the original JSR FCOMPL is missing, and the labels in the new version got shuffled down a line as a result. I'm not sure where the comment is referring to, because the PDF listing of the old code does have the JSR FCOMPL. I think those labels should be shuffled back up to how they are in the original listing, so that FSUB does the complement before falling down into FADD.

When this shuffle happened, The FSUB label was moved down one line along with the RTSN label above it. It looks like, as an attempt to compensate, all locations that were doing a JSR/JMP FSUB were changed to JSR/JMP RTSN (3 places, 2 outside my section). This jumps to the correct place but using the wrong label.

I propose moving the RTSN label and FSUB label back where they should be and changing all of the JSR RTSN back to JSR FSUB. This makes the code easier to read because you are trying to subtract in those locations. The changes outside my section are at $2597 and $25ED in Mike's section. If I can get someone else to double check this and concur, then I will make that change in my section. [edit - adding location of this routine] The FSUB routine can be found on page 89 (in the header at the top of each page) of the FOCAL-65_PRI_V3D_Source-compressed.pdf file (although my reader says it is page 91) and line 3135 of Focal-CompletedSource_v3d_Aresco.txt.

I also have magic numbers in all of the jump tables for the various commands that could be replaced with high/low bytes using labels. This might make those routines more relocatable for future programmers trying to port this to their system. Do you want me to change those to labels or leave them as hex numbers?

Also, how are we collating our edits?

Good catch, Sam. To answer a few questions:

The comment about the missing JSR FCOMPL instruction at that point in the Aresco source, refers to the fact that Aresco (when they did their KIM-1 conversion of the Denver 6502 Group original version in 1977) simply left it out. The history of this code is a little twisted, IMO. When I spoke with Wayne Wall several months ago, he was unaware that there even was another version from his original. What Wayne and Friends provided the 6502 Program Exchange in Reno, NV, is the big PDF we've been calling "the original." However, in 6502 User Notes, Eric Rehnke commented various times about the two versions. The Aresco version (also from 1977) is what I'm trying to document as it's the only runable object code we've had for the KIM-1 (and clone/replica) machines, and even that probably would have been lost if not for Hans Otten. I did not intend for the Aresco to become the Prog/Ex version. I kind of think of the Aresco version as a sub-species. After years of looking on the internet, we thought the source code was lost for good. Having only a generic listing of the Aresco object code was the starting point, and we didn't aim to convert this, only document it so folks could tinker with it much more easily.

But I'm off on a tangent. To be honest, I cannot say whether relabeling the FSUB code is the right thing to do. Aresco did what they did, and we'll never know why. I did fire up FOCAL-65 on my PAL-1 machine and made a number of arcane and fun subtractions, and it all works fine business (except when I overflowed the F.P. accumulator, and the answer was still right to six decimal places!). So...if it ain't broke??? <shrug> I'd like to hear what the rest of the group thinks...or anyone else, for that matter.

I think you're right, SamCo, that defining labels for the function and command look-up and jump tables is a good idea. Does anyone else agree?

Finally, when each guy is done with his 'chunk', send it back to me and I'll put it together, and then we can assemble off of one single source and test.

Dave

That sounds good to me (attempting to create source code for existing object code). The tables that have the address of the FSUB function have the correct starting address and include the JSR FCOMPL, which is why the subtract function is working properly, but I will have to use the "wrong" label in those tables if you want me to change them from magic numbers to high and low bytes of labels (unless we fix the labels to be like the PDF). Either way is doable.

I'm good with whatever you think makes the most sense for those (archeologists?) who will come after us.