Thanks for the heads up, Sam. I am certainly willing to follow your lead, since it seems that we agree about all of the points that you made. BTW, I'm not sure if anyone else noticed, but those are five-byte WOZ floats, which I quickly recognized while I was accidentally messing around with the source $1000 bytes away from my section.

Dave, which assembler are we targeting? After I submit my section for review, I want to play with the whole thing far enough to get it to assemble and execute in the Kowalski simulator, but I totally understand if you want to keep things KIM-centric on your end.

_________________
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)

I'd recommend that best practice here is to capture exactly what's on the printout or in the scans.

Once you have as accurate a capture as you can get, you can modify it to make it more usable. You keep the clean copy as an archive.

Source control systems can help with keeping several versions of a thing - can also help with merging in successive contributions, or later corrections.

I see your point too, Ed.

This situation is a bit unique, in that we have a 17"-wide fan-fold .LST file that targets the TIM and uses an assembler which is probably long lost. It also looks to be highly resistant to current OCR technology. Dave found a working binary (or two) that ported it from the original TIM to the KIM (and Apple, I think). I believe that Dave has a primary goal to make the KIM version more than just a binary, but also an .ASM source, so he and others can play with it more easily. The TIM .LST printout is the best chance to do that in a useful manner (much better than a generic disassembly of the binary). Capturing the exact printout character for character is a secondary goal and may be delegated to other humans (or improved OCR technology, if and when). Please correct me if I'm mistaken, Dave.

_________________
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)

Ah yes, makes sense - carry on!

[edited to fix spelling]
I think fixing the labels so they are like the PDF listing makes the most sense. That means the RTSN label moves up a line (it's literally the RTS for the "Normalization" procedure and the FSUB moves up a line so it's the label that will need to be used for subtraction, and the SWPALG (swap or align) label will be brought back to where FSUB used to be. All of the references to these labels are in my section except for the following two:

Code:

FOCAL-CompletedSource_v3d_Aresco.txt Line 1063
          JSR RTSN   ; SUBTRACT COUNTER FROM UPPER LIMIT
becomes
          JSR FSUB   ; SUBTRACT COUNTER FROM UPPER LIMIT

and
FOCAL-CompletedSource_v3d_Aresco.txt Line 1107
          JSR RTSN   ; SUBTRACT OFF THE GROUP NUMBER
becomes
          JSR FSUB   ; SUBTRACT OFF THE GROUP NUMBER

Even from those tiny snippets, I think you can see that the code now makes sense with the comments. Note that this should result in the SAME OBJECT CODE as before, but the source code will be much easier for a future code archeologist to deal with.

I've finished my section and have only one other mystery concerning a LDY# that I need help with:

was typed in as (line 3261) which looks like it is missing the # on LDY, however in the listing for the new source code we are developing, it shows this: and that A0 on the LDY line looks like it is assembling as LDY immediate, even though there is no # in front of the operand. Is there supposed to be a # on the operand? I think so. The mystery to me is how the listing has the correct opcode even though I think the source code has an error.

That's the only true error (if it is an error) I found in my section. Kudos to the typists who typed this all in from the PDF listing.

That should definitely be an immediate, Sam. This is where context matters, since the MOVXY routine to which it JSRs uses both registers as "from" and "to" zero-page pointers (by self-modifying). Context awareness is what separates us humans from OCR engines, at least for now.

That missing # (and trust me, it's not the only one!) might have been very hard to debug, because it would silently corrupt zero-page in a way that could take many thousands of subsequent instructions to manifest itself. IOW, good catch!

_________________
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)

> The mystery to me is how the listing has the correct opcode even though I think the source code has an error.

That is a mystery. Any possibility at all that the assembler has a bug???

No, Ed. I believe that the .LST file to which Sam refers has been manually massaged by Dave or Nils. Those guys laid A LOT of groundwork before sharing what they had with the team, and they were no doubt cramping up and seeing double at times.

_________________
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)

Triple, occasionally!

Yes, I can confirm that the only 6502 sources that exists are for the MOS TIM monitor (vers 3D) from the Denver 6502 Group and the Apple II with an add-on FPU (v4). The only executable binary we have is the Aresco version. Nils and I reconstructed the Aresco source from a simple disassembly of the Aresco binary and then dug into the detective work, correlating with the 6502Group's TIM source.

It IS an odd situation. But I also agree that the 6502Group TIM version deserves to be preserved and even typed up so it can run, but in the KIM-1/replica world, I don't know of anyone who is using the TIM. Having commented source for the one executable we have seemed to make the most sense for now.

As to target assembler, I'm sure everyone has their favorite. I'm not a fan of CC65 (mainly because it seems very complicated to me), but I'm open to suggestions. FWIW, for 6502 stuff I typically use crasm or Norbert Landsteiner's on-line assember at masswerk.at for quickie things (William Colley's A68 - which I really enjoy using - for 6800 stuff).

My first thought was along the lines of what BigEd was thinking (bad assembler?), but this was my second thought and it seemed more likely to me. I'll fix that missing # for an immediate operand in my source code section. Thanks.

Oh, I see, if the LST file isn't (exactly) a listing, then that's another case!

TIM (6530-004) is used! It is in the Superjolt for example, which is rare but I have some: http://retro.hansotten.nl/superjolt-and-tim-6530/

https://forum.classic-computing.de/foru ... mos-tim-1/ for a current TIM design, some TIM IC's were available, see also the viewtopic.php?f=4&t=6711&p=85721&hilit=6530+004#p85721

I built a TIM-1 simulator, so I could play with the (very simple) TIM monitor: http://retro.hansotten.nl/timsim/

The only Focal-V3D binary I know of comes as dump from my KIM-1 cassette, the manual scanned from my version: http://retro.hansotten.nl/6502-sbc/kim- ... are/#focal With a partial disassembly by the late Paul R. Santa-Maria and me. Runs on the KIM-1 and clones.

I think this has become an important question. I have tables at the end of my section - mostly addresses of functions used for jumping. The current code that we are working on has magic numbers (eg. the addresses are just hard-coded as .BYTE directives with hex numbers after them). The PDF code uses the names of the functions, however it uses an .HBYTE directive I haven't seen before:
I'm used to the syntax:I do see ca65 supports .HIBYTE and .LOBYTE directives. If there is a target assembler, or even a list of desired assemblers, then we can try to make the code as compatible as possible.

While most of the tables will assemble and should work as they are (one had to be fixed up), it would be nice to restore them to using the labels. It would allow anyone who wants to edit the code in the future to not have to worry about adding or subtracting a byte, which will mess up the "magic number" method and not be obvious.

[Edit] I see an earlier message is actually asking for suggestions for a target assembler. I'll recommend 64tass as there is a Windows executable, it's available for many (but not all) linuxes from the package manager, and it is super easy to compile on any system (eg. it has virtually no dependencies on other packages - just need a C compiler and make). It uses the >LABEL and <LABEL method shown above, as do many other assemblers.

I have been privately playing with it on the Kowalski simulator, but I haven't been able to finish the second pass yet. So far, it's just been missing equates and similar. It also thinks that A is a label in instructions like LSR A, but that was a super easy pass-one fix. If I kludge it together well enough to get an error-free assembly, I'll verify that it's binary identical and share it here, where you guys can use it any way you want. I promise that it won't be finely polished without the help of the other team members, but it'll be a foot in the door.

I intend to get FOCAL-65 working on the Kowalski console, like my own VTLC02 and my port of Ken's Z80 MINT interpreter (work in progress), which should be enough 8-bit interpreters to satisfy my curiosity for now. FOCAL-65 is definitely the biggest of the bunch, but it's closer to assembling than MINT is at present. I'll start a fresh MINT thread when I can get two clean passes and a prompt.

Please, if any of you have questions or comments about VTLC02 or MINT, PM me for further info, so as not to pollute Dave's thread.

_________________
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)

I was able to get a rather sketchy version of the source through both passes on the Kowalski assembler, and the binary looks like it's a very good match all the way up to $34AA inside the KIM-specific character I/O routines, when it starts to obviously diverge from the .PTP file Dave supplied (presumably the binary he has been executing on his actual hardware). It's certainly not ready for prime-time, but if any of the team members want to take a glance over it to see what's going on, I can PM a copy of the Kowalski version source. Although it made it through both passes cleanly, it's still quite a way from executing in the simulator, since I haven't even touched the I/O stuff.

_________________
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)