6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Thu Nov 21, 2024 2:55 pm

All times are UTC




Post new topic Reply to topic  [ 52 posts ]  Go to page Previous  1, 2, 3, 4  Next
Author Message
PostPosted: Sun Dec 24, 2023 10:04 pm 
Offline
User avatar

Joined: Sat Aug 13, 2022 9:32 pm
Posts: 10
Location: near Portland, OR, USA
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.


Top
 Profile  
Reply with quote  
PostPosted: Thu Dec 28, 2023 9:52 pm 
Offline

Joined: Sun May 13, 2018 5:49 pm
Posts: 255
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.


Top
 Profile  
Reply with quote  
PostPosted: Thu Dec 28, 2023 10:28 pm 
Offline
User avatar

Joined: Sun Jun 30, 2013 10:26 pm
Posts: 1949
Location: Sacramento, CA, USA
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.

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


Top
 Profile  
Reply with quote  
PostPosted: Sun Dec 31, 2023 7:14 pm 
Offline
User avatar

Joined: Sat Aug 13, 2022 9:32 pm
Posts: 10
Location: near Portland, OR, USA
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.


Top
 Profile  
Reply with quote  
PostPosted: Mon Jan 22, 2024 8:46 pm 
Offline

Joined: Sun May 13, 2018 5:49 pm
Posts: 255
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.


Top
 Profile  
Reply with quote  
PostPosted: Mon Jan 22, 2024 11:45 pm 
Offline
User avatar

Joined: Sun Jun 30, 2013 10:26 pm
Posts: 1949
Location: Sacramento, CA, USA
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)


Top
 Profile  
Reply with quote  
PostPosted: Mon Jan 29, 2024 9:41 pm 
Offline

Joined: Fri Apr 15, 2016 1:03 am
Posts: 140
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.


Attachments:
20240128.zip [96.36 KiB]
Downloaded 33 times
Top
 Profile  
Reply with quote  
PostPosted: Wed Jan 31, 2024 2:43 pm 
Offline

Joined: Sun May 13, 2018 5:49 pm
Posts: 255
leepivonka wrote:
This was assembled with CA65 from the CC65 suite.
Thanks - I'm hoping to have time this weekend to work on this some more, and I'll take a look. It would be nice to end up with source assembly that can be compiled with Kowalski (what I am using now) and other assemblers with minimal fuss, so I'll take a look at your code when I make it to that point - I'm especially interested in the directives you have at the top, as I could put those in a comment block.

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.


Top
 Profile  
Reply with quote  
PostPosted: Wed Jan 31, 2024 9:46 pm 
Offline

Joined: Tue Oct 24, 2017 1:08 am
Posts: 10
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


Top
 Profile  
Reply with quote  
PostPosted: Thu Feb 01, 2024 2:25 pm 
Offline
User avatar

Joined: Fri Oct 31, 2003 10:00 pm
Posts: 200
Attachment:
SECONDRUN.jpg
SECONDRUN.jpg [ 35.38 KiB | Viewed 1105 times ]
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.
Code:
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         

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/


Attachments:
secondrun.jpg
secondrun.jpg [ 34.45 KiB | Viewed 1105 times ]
Top
 Profile  
Reply with quote  
PostPosted: Thu Feb 01, 2024 2:29 pm 
Offline
User avatar

Joined: Fri Oct 31, 2003 10:00 pm
Posts: 200
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

A quick find! That page is up since yesterday!


Top
 Profile  
Reply with quote  
PostPosted: Thu Feb 01, 2024 2:37 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10985
Location: England
Great reconstruction and preservation, Hans!


Top
 Profile  
Reply with quote  
PostPosted: Fri Feb 02, 2024 12:31 pm 
Offline

Joined: Thu Mar 12, 2020 10:04 pm
Posts: 704
Location: North Tejas
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.

For gits and shiggles, I ran your source code through my cross-assembler.

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!


Top
 Profile  
Reply with quote  
PostPosted: Fri Feb 02, 2024 3:09 pm 
Offline
User avatar

Joined: Fri Oct 31, 2003 10:00 pm
Posts: 200
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.


Attachments:
firstrun.jpg
firstrun.jpg [ 62.26 KiB | Viewed 1051 times ]
Top
 Profile  
Reply with quote  
PostPosted: Fri Feb 02, 2024 4:16 pm 
Offline
User avatar

Joined: Sun Jun 30, 2013 10:26 pm
Posts: 1949
Location: Sacramento, CA, USA
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.

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


Last edited by barrym95838 on Fri Feb 02, 2024 4:21 pm, edited 1 time in total.

Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 52 posts ]  Go to page Previous  1, 2, 3, 4  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 0 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: