FOCAL-65 source code proofreading needed
- Fishhack66
- Posts: 10
- Joined: 13 Aug 2022
- Location: near Portland, OR, USA
Re: FOCAL-65 source code proofreading needed
I'm OK with the Kowalski assembler. I like that it can run on all the major platforms (w/ WINE on Mac/*nix). Thoughts? Personally, I don't have a real preference, and the source file we're building is typical and ought to assemble on most systems. Still, Sam's point is a good one: when dealing with data tables, some assemblers are quite specific how those should be formatted. But if Mike's getting good results with Kowalski, that's great.
The MOS .PTP file I have is a lightly patched version of Hans O's original cassette-obtained binary code. The KIM-1 I/O should be easy to patch for most systems as it's just INCH, OUTCH, and an echo suppression method for the output.
Merry Christmas, all.
The MOS .PTP file I have is a lightly patched version of Hans O's original cassette-obtained binary code. The KIM-1 I/O should be easy to patch for most systems as it's just INCH, OUTCH, and an echo suppression method for the output.
Merry Christmas, all.
Re: FOCAL-65 source code proofreading needed
The Kowalski assembler/simulator should be a reasonable target. It supports the .BYTE along with > and < for the high/low bytes and that is pretty common among assemblers, so I'll use that syntax for the tables. I'm almost done with them and will send you my section shortly.
A few notes about this assembler:
The * = near the top will need to be changed to *= (no space between * and =) or into a .ORG statement.
You can't use an instruction mnemonic as a label, so the label "CLI" will need to be modified (I put an underscore in front and that seemed to fix that particular issue).
The assembler assembles to memory and you need to save the output with "File->Save Code" in the menus. "Code", in this case, is the machine code. There are options for hex or binary formats.
If you want a listing file, you need to go into the "Simulator->Options->Assembler tab" to turn it on and give a file name for it.
The .chm help file is a bit difficult to open these days - I use kchmviewer on linux, which works very well. The wine program hh did not read it properly (no index, which makes it impossible to browse).
The Kowalski simulator also has super easy to use I/O, so it will be easy to modify the INKEY and TVOUT (labels from the PDF) routines to test with the simulator if needed. It looks like there are also KIM simulators available.
barrym will likely have more pointers as it sounds like he's made it pretty far along in getting it to assemble with this assembler.
A few notes about this assembler:
The * = near the top will need to be changed to *= (no space between * and =) or into a .ORG statement.
You can't use an instruction mnemonic as a label, so the label "CLI" will need to be modified (I put an underscore in front and that seemed to fix that particular issue).
The assembler assembles to memory and you need to save the output with "File->Save Code" in the menus. "Code", in this case, is the machine code. There are options for hex or binary formats.
If you want a listing file, you need to go into the "Simulator->Options->Assembler tab" to turn it on and give a file name for it.
The .chm help file is a bit difficult to open these days - I use kchmviewer on linux, which works very well. The wine program hh did not read it properly (no index, which makes it impossible to browse).
The Kowalski simulator also has super easy to use I/O, so it will be easy to modify the INKEY and TVOUT (labels from the PDF) routines to test with the simulator if needed. It looks like there are also KIM simulators available.
barrym will likely have more pointers as it sounds like he's made it pretty far along in getting it to assemble with this assembler.
- barrym95838
- Posts: 2056
- Joined: 30 Jun 2013
- Location: Sacramento, CA, USA
Re: FOCAL-65 source code proofreading needed
We don't have any version control at present, and even if we did I wouldn't know how to use it properly, so we should nominate Sam or Dave to merge everything into a single source file. My private version of the source assembles cleanly, but it still has a bunch of hard-coded constants and very likely some logic errors as well. I'm at work right now, but I encourage Sam and Dave to work out who wants to administrate (in order to keep the number of slightly different private versions down to a minimum) ...
I don't feel adequately qualified to volunteer for that specific task, but I won't hesitate to share what I have with any or every interested party, to use as he or she sees fit. Dave's the OG, but Sam seems to really have his act together, so I have no personal preference on whom to nominate.
I don't feel adequately qualified to volunteer for that specific task, but I won't hesitate to share what I have with any or every interested party, to use as he or she sees fit. Dave's the OG, but Sam seems to really have his act together, so I have no personal preference on whom to nominate.
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)
Mike B. (about me) (learning how to github)
- Fishhack66
- Posts: 10
- Joined: 13 Aug 2022
- Location: near Portland, OR, USA
Re: FOCAL-65 source code proofreading needed
Hi, folks. SamCoVT has volunteered to curate the proofread code, assemble it, etc., to create a "final" version. I still need to get two chunks; when I get those, I'll put it all together into one file and turn it over to Sam for the home stretch. Big thanks to Sam for taking this on.
Re: FOCAL-65 source code proofreading needed
I've gotten everything to assemble using the Kowalski simulator/assembler and the initial results are good. There is well over 95% that is a binary match to the original PTP (Paper Tape) version. If you want to see the binary versions for yourself, you can check them out at
https://github.com/SamCoVT/FOCAL65_KIM1
I'm using dhex to do the binary comparison (compiled it from source) on Linux. The command line arguments that line up the various binary versions are shown in the README.md on the repository (displayed at the very bottom of the main page in the repo).
Can I just verify that the goal to get a perfect binary match to the paper tape version (filename "FOCAL-65_(patched).PTP" in the "original_source" folder of my repository)? Does this version run properly on real hardware? I'm having a difficult time getting it to work in a simulator (using Hans Otten's KIM1SIM with special Focal V3D break checking enabled). I can press a first letter, but it errors out when I press a second (like T SPACE will error on the SPACEbar being pressed and SET will error on the E being pressed).
It appears there may be a couple of patches that we would need to "undo" to get a full binary match and the largest of these appears to do with I/O. There is also a section in the PTP file, after the copyright right at the end, that does not appear in the assembly version. I can't tell if it's data structures for a "blank" program, or if the person that made the PTP just grabbed a bit of extra RAM at the end and they are garbage values that don't need to be replicated.
I'll poke and prod it a bit more to see if I can find more issues that cause a binary difference, but that probably won't be for a weekend or two. I'm very encouraged by the high match rate that has already been created.
https://github.com/SamCoVT/FOCAL65_KIM1
I'm using dhex to do the binary comparison (compiled it from source) on Linux. The command line arguments that line up the various binary versions are shown in the README.md on the repository (displayed at the very bottom of the main page in the repo).
Can I just verify that the goal to get a perfect binary match to the paper tape version (filename "FOCAL-65_(patched).PTP" in the "original_source" folder of my repository)? Does this version run properly on real hardware? I'm having a difficult time getting it to work in a simulator (using Hans Otten's KIM1SIM with special Focal V3D break checking enabled). I can press a first letter, but it errors out when I press a second (like T SPACE will error on the SPACEbar being pressed and SET will error on the E being pressed).
It appears there may be a couple of patches that we would need to "undo" to get a full binary match and the largest of these appears to do with I/O. There is also a section in the PTP file, after the copyright right at the end, that does not appear in the assembly version. I can't tell if it's data structures for a "blank" program, or if the person that made the PTP just grabbed a bit of extra RAM at the end and they are garbage values that don't need to be replicated.
I'll poke and prod it a bit more to see if I can find more issues that cause a binary difference, but that probably won't be for a weekend or two. I'm very encouraged by the high match rate that has already been created.
- barrym95838
- Posts: 2056
- Joined: 30 Jun 2013
- Location: Sacramento, CA, USA
Re: FOCAL-65 source code proofreading needed
Nice work, Sam. Dave should be around shortly to confirm this, but I believe that he was successfully running that .PTP binary on his flesh-and-blood PAL-1, which is very similar to a KIM-1, differing only slightly due to the 6532 vs. 6530 details.
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)
Mike B. (about me) (learning how to github)
-
leepivonka
- Posts: 167
- Joined: 15 Apr 2016
Re: FOCAL-65 source code proofreading needed
I've been playing with Sam's source. Here is a version that
matches the binary FOCALM.BIN in kimfocalv3d.zip (except for system porting)
and is similar to the source in FOCAL-65_PRI_V3D_Source-compressed.pdf
This was assembled with CA65 from the CC65 suite.
matches the binary FOCALM.BIN in kimfocalv3d.zip (except for system porting)
and is similar to the source in FOCAL-65_PRI_V3D_Source-compressed.pdf
This was assembled with CA65 from the CC65 suite.
- Attachments
-
- 20240128.zip
- (96.36 KiB) Downloaded 104 times
Re: FOCAL-65 source code proofreading needed
leepivonka wrote:
This was assembled with CA65 from the CC65 suite.
It's nice to see the Demo1.txt file where you show a sample run of it working. I've been having issues with the original PTP (MOS PaperTaPe format) version I'm working on that just crashes when I try to use a T command to type a value - it crashes the instant I type the space after the T. I'm using Hans Otten's KIM1 simulator, and I've tried turning on and off the special FOCAL I/O handling included in that simulator with no change. I'll have to play with it more to see if I can figure out what the problem is. I do have two different versions of the I/O routines for the KIM, so it's possible Hans' simulator will like the other I/O code better. I'd love to have code that works on real hardware as well as the simulator with no changes, so I'm hoping it's that simple. I do plan on adding I/O routines for the Kowalski simulator as well, but I *think* those will be easy as the I/O on that simulator is very simple.
-
Uncle Warthog
- Posts: 14
- Joined: 24 Oct 2017
Re: FOCAL-65 source code proofreading needed
Out of curiosity, has anyone tried the TIM version on Hans' TIM (i.e. JOLT computer) simulator? Also, I'm not sure but I think the original assembler used might have been Aresco's version of the MOS resident assembler, https://www.pagetable.com/?p=1522
Re: FOCAL-65 source code proofreading needed
I took a different route in my work to reconstruct Focal-65 from source.
My goals are to preserve the original work as much as possible, to honor the work of the original author(s).
This means for me staying as close as possible to the original!
Only when that is looking good, I may make it better as derived work: adapt to video terminals, make it ROMmable (it has self modifying code), init data in zeropage, move code out of zeropage, add some nice patches as described in the User manual and several articles from the old days.
I took the listing I found, cleaned and cropped it to make it better readable and typed it in, exactly as it is on paper. Same labels, uppercase, comments verbatim, same line numbers.
Of course I had to adapt the assemble syntax a bit, the PAL-65 assembler (made with macro's in the DEC PDP assembler!) is not available to me.
Once it assembled I checked the binary output line for line to the listing. Amazing how many forgotten '#'s may get unnoticed on first sight!
The resulting binary tested in my TIM Simulator and seems OK.
Next I replaced the TIM I/O package with a KIM-1 I/O package and tested that on the KIM-1 Simulator, with success so far. I did not check yet if this is Focal-65E for the kIM-1 yet.
The source can now easily be used in any 6502 SBC, just add character I/O and fill in the IRQ/BRK vector.
This is the code for KIM TTY I/O package I use in my reconstructed Denver 6502 Group source.
It works fine in the KIM-1 Simulator with the Focal V3D selected in Settings. Based upon this: http://retro.hansotten.nl/6502-sbc/kim- ... im-1-echo/
Note that when looking at the source, zeropage in the Denver Group 65 (distributed by the Program Exchange) is mostly zero's. Very few locations have a value.
Further note that the binary of the Aresco version, about 90% perhaps identical to the TIM version, where the disassembly work in this thread is based upon, comes from a dump I made in 2004 of a cassette tape that survived. The dump was not the original clean one as distributed by the Program Exchange, but from a copy made after running the interpreter. So the zeropage and perhaps the code dump is polluted with runtime information. Also the whole zeropage is dumped, which is of course too much.
I am afraid aiming to have source to output the same as the dump will be a bit polluted.
The reconstructed TIM (and KIM-1) versions are clean!
Also note that Wayne based his design upon the DEC Focal version. In the DEC-08-AJBB-DL Advanced FOCAL Technical Specification April 1969 you can find the flowcharts and symbols etc used in the Focal-65 source. Helps a lot to understand why it is written this way.
You can find my work at a page dedicated to Focal-65 here: http://retro.hansotten.nl/6502-sbc/focal-65-v3d/
My goals are to preserve the original work as much as possible, to honor the work of the original author(s).
This means for me staying as close as possible to the original!
Only when that is looking good, I may make it better as derived work: adapt to video terminals, make it ROMmable (it has self modifying code), init data in zeropage, move code out of zeropage, add some nice patches as described in the User manual and several articles from the old days.
I took the listing I found, cleaned and cropped it to make it better readable and typed it in, exactly as it is on paper. Same labels, uppercase, comments verbatim, same line numbers.
Of course I had to adapt the assemble syntax a bit, the PAL-65 assembler (made with macro's in the DEC PDP assembler!) is not available to me.
Once it assembled I checked the binary output line for line to the listing. Amazing how many forgotten '#'s may get unnoticed on first sight!
The resulting binary tested in my TIM Simulator and seems OK.
Next I replaced the TIM I/O package with a KIM-1 I/O package and tested that on the KIM-1 Simulator, with success so far. I did not check yet if this is Focal-65E for the kIM-1 yet.
The source can now easily be used in any 6502 SBC, just add character I/O and fill in the IRQ/BRK vector.
This is the code for KIM TTY I/O package I use in my reconstructed Denver 6502 Group source.
Code: Select all
0313 00A9 20 A0 1E OUT JSR OUTCH ; TTY OUTCH in KIM-1 ROM
0314 00AC 18 CLC
0315 00AD 60 RTS
0316 00AE ; KIM-1 echo (ignores ECHFLG for now)
0317 00AE E6 76 IN INC HASH ; SEED
0318 00B0 2C 40 17 BIT SBA ; KIM-1 6532 PIA A DATA REGISTER
0319 00B3 30 F9 BMI IN ; WAIT FOR INCOMING CHARACTER
0320 00B5 A5 6B LDA ECHFLG ; TEST IF WE ARE TO ECHO
0321 00B7 F0 08 BEQ NOECH ; BRANCH IF NOT
0322 00B9 AD 42 17 LDA SBD ; KIM-1 6532 PIA B DATA REGISTER
0323 00BC 29 FE AND #$FE ; INHIBIT ECHO VIA PB0
0324 00BE 8D 42 17 STA SBD
0325 00C1 20 5A 1E NOECH JSR GETCH ; GETCH IN KIM-1 ROM
0326 00C4 48 PHA
0327 00C5 AD 42 17 LDA SBD ; THE ECHO DEFEAT
0328 00C8 29 FE AND #$FE
0329 00CA 09 01 ORA #$01 ; RESTORE PIA PB0
0330 00CC 8D 42 17 STA SBD
0331 00CF 68 PLA
0332 00D0 18 CLC
0333 00D1 60 RTS
Note that when looking at the source, zeropage in the Denver Group 65 (distributed by the Program Exchange) is mostly zero's. Very few locations have a value.
Further note that the binary of the Aresco version, about 90% perhaps identical to the TIM version, where the disassembly work in this thread is based upon, comes from a dump I made in 2004 of a cassette tape that survived. The dump was not the original clean one as distributed by the Program Exchange, but from a copy made after running the interpreter. So the zeropage and perhaps the code dump is polluted with runtime information. Also the whole zeropage is dumped, which is of course too much.
I am afraid aiming to have source to output the same as the dump will be a bit polluted.
The reconstructed TIM (and KIM-1) versions are clean!
Also note that Wayne based his design upon the DEC Focal version. In the DEC-08-AJBB-DL Advanced FOCAL Technical Specification April 1969 you can find the flowcharts and symbols etc used in the Focal-65 source. Helps a lot to understand why it is written this way.
You can find my work at a page dedicated to Focal-65 here: http://retro.hansotten.nl/6502-sbc/focal-65-v3d/
Re: FOCAL-65 source code proofreading needed
Uncle Warthog wrote:
Out of curiosity, has anyone tried the TIM version on Hans' TIM (i.e. JOLT computer) simulator? Also, I'm not sure but I think the original assembler used might have been Aresco's version of the MOS resident assembler, https://www.pagetable.com/?p=1522
Re: FOCAL-65 source code proofreading needed
Great reconstruction and preservation, Hans!
Re: FOCAL-65 source code proofreading needed
HansO wrote:
My goals are to preserve the original work as much as possible, to honor the work of the original author(s).
This means for me staying as close as possible to the original!
Only when that is looking good, I may make it better as derived work: adapt to video terminals, make it ROMmable (it has self modifying code), init data in zeropage, move code out of zeropage, add some nice patches as described in the User manual and several articles from the old days.
I took the listing I found, cleaned and cropped it to make it better readable and typed it in, exactly as it is on paper. Same labels, uppercase, comments verbatim, same line numbers.
Of course I had to adapt the assemble syntax a bit, the PAL-65 assembler (made with macro's in the DEC PDP assembler!) is not available to me.
Once it assembled I checked the binary output line for line to the listing. Amazing how many forgotten '#'s may get unnoticed on first sight!
The resulting binary tested in my TIM Simulator and seems OK.
This means for me staying as close as possible to the original!
Only when that is looking good, I may make it better as derived work: adapt to video terminals, make it ROMmable (it has self modifying code), init data in zeropage, move code out of zeropage, add some nice patches as described in the User manual and several articles from the old days.
I took the listing I found, cleaned and cropped it to make it better readable and typed it in, exactly as it is on paper. Same labels, uppercase, comments verbatim, same line numbers.
Of course I had to adapt the assemble syntax a bit, the PAL-65 assembler (made with macro's in the DEC PDP assembler!) is not available to me.
Once it assembled I checked the binary output line for line to the listing. Amazing how many forgotten '#'s may get unnoticed on first sight!
The resulting binary tested in my TIM Simulator and seems OK.
It gave me 70 errors, way fewer than I was expecting.
Only one I believe is a true issue: line #708 begins a comment line with a colon instead of a semicolon. Was that intended?
The remainder are things I have been intending to fix:
* Allow whitespace before and within expressions
* Support .text directive for declaring ASCII character strings
Or can relatively easily fix:
* Allow use of '$' to represent the current program counter in addition to '*'
* Change .byte to not issue an error for quantities too large to represent within a single byte. Either an option to automatically accept and truncate or issue a warning instead along with an option to suppress warnings.
Surprisingly, those are it!
Re: FOCAL-65 source code proofreading needed
It was an easy job to reconstruct the source of the Aresco Focal version from the TIM source.
I took the binary of the tape dump from 1978, the interpreter part.
And compared it with the binary output of the assembler.
The TIM source was the beginning of the Aresco source. I had also the disassembly, made in 2004, opened to see the code where differences were seen.
Any difference between the binaries were fixed in the source step by step. JMPs and JSRs and access to tables ignored, those differences disappeared of course once the source got fixed.
So comforting to see more and more parts becoming equal!
Amazing it took about only some hours to get the source in a state that the output was a binary equivalent of the tape dump.
It was also a test of the quality of the original TIM source as typed in. I found only one! error in an unused part of a table.
The reconstructed binary works in my KIM-1 Simulator. No surprise, it did that for several years. but proofs that the zeropage part output of the assembly is also OK
I ignored the polluted tape dump of zeropage and let the source reconstruct that.
I also ignored the extra bytes dumped after the interpreter, another artefact of the tape dump in 1978.
So now I can present a clean and original reconstructed source of the Focal-65 Aresco version too. Source and binaries.
Ready now for some improvements, like backspace handling, (re)move self-modifying code, add ROR code for speed, init zeropage instead of loading. Read the old articles and contribute!
Bill, thanks for checking the source with your assembler. Indeed line 708 is no good, but my assembler ignored it. Fixed now.
I took the binary of the tape dump from 1978, the interpreter part.
And compared it with the binary output of the assembler.
The TIM source was the beginning of the Aresco source. I had also the disassembly, made in 2004, opened to see the code where differences were seen.
Any difference between the binaries were fixed in the source step by step. JMPs and JSRs and access to tables ignored, those differences disappeared of course once the source got fixed.
So comforting to see more and more parts becoming equal!
Amazing it took about only some hours to get the source in a state that the output was a binary equivalent of the tape dump.
It was also a test of the quality of the original TIM source as typed in. I found only one! error in an unused part of a table.
The reconstructed binary works in my KIM-1 Simulator. No surprise, it did that for several years. but proofs that the zeropage part output of the assembly is also OK
I ignored the polluted tape dump of zeropage and let the source reconstruct that.
I also ignored the extra bytes dumped after the interpreter, another artefact of the tape dump in 1978.
So now I can present a clean and original reconstructed source of the Focal-65 Aresco version too. Source and binaries.
Ready now for some improvements, like backspace handling, (re)move self-modifying code, add ROR code for speed, init zeropage instead of loading. Read the old articles and contribute!
Bill, thanks for checking the source with your assembler. Indeed line 708 is no good, but my assembler ignored it. Fixed now.
- barrym95838
- Posts: 2056
- Joined: 30 Jun 2013
- Location: Sacramento, CA, USA
Re: FOCAL-65 source code proofreading needed
Excellent work, Hans! I don't know how close FOCAL-65 came to extinction, but your efforts and the efforts of all the participants in this thread have guaranteed that it should now survive at least until the end of civilization as we know it. Parallel and redundant efforts with slightly different end goals should be celebrated and encouraged, because diversity supports proliferation, and proliferation of a good thing is generally just good.
Congratulations, everyone! Keep the 65xx dream alive.
Congratulations, everyone! Keep the 65xx dream alive.
Last edited by barrym95838 on Fri Feb 02, 2024 4:21 pm, edited 1 time in total.
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)
Mike B. (about me) (learning how to github)