FLEX for the 6502 or building a compatible operating system.

[BigEd]

Hee hee!

[BillG]

Another set of tests, this time of adding variables.

Note that a planned future enhancement will place as many variables as possible in the zero page.

The lesson is clear: for best results, use unsigned variables whenever possible.

Code: Select all

                          00080 ; 00001 program Test;
                          00081 ; 00002 
                          00082 ; 00003   var
                          00083 ; 00004     B                           : byte;
                          00084 ; 00005     B2                          : byte;
                          00085 ; 00006     Ch                          : char;
                          00086 ; 00007     Ch2                         : char;
                          00087 ; 00008     I                           : integer;
                          00088 ; 00009     S                           : shortint;
                          00089 ; 00010     S2                          : shortint;
                          00090 ; 00011     W                           : word;
                          00091 ; 00012 
                          00092 ; 00013   begin
                          00093 ; 00014     W := W + S;
 0B09 18              [2] 00094          clc
 0B0A AD 10F9         [4] 00095          lda    W_
 0B0D 6D 10F8         [4] 00096          adc    S_
 0B10 AA              [2] 00097          tax
 0B11 AD 10F8         [4] 00098          lda    S_
 0B14 09 7F           [2] 00099          ora    #$7F
 0B16 30 02 (0B1A)  [2/3] 00100          bmi    2f
 0B18 A9 00           [2] 00101          lda    #0
 0B1A                     00102 2:
 0B1A 6D 10FA         [4] 00103          adc    W_+1
 0B1D 8E 10F9         [4] 00104          stx    W_
 0B20 8D 10FA         [4] 00105          sta    W_+1
                          00106 ; 00015     W := S + W;
 0B23 18              [2] 00107          clc
 0B24 AD 10F8         [4] 00108          lda    S_
 0B27 6D 10F9         [4] 00109          adc    W_
 0B2A AA              [2] 00110          tax
 0B2B AD 10F8         [4] 00111          lda    S_
 0B2E 09 7F           [2] 00112          ora    #$7F
 0B30 30 02 (0B34)  [2/3] 00113          bmi    2f
 0B32 A9 00           [2] 00114          lda    #0
 0B34                     00115 2:
 0B34 6D 10FA         [4] 00116          adc    W_+1
 0B37 8E 10F9         [4] 00117          stx    W_
 0B3A 8D 10FA         [4] 00118          sta    W_+1
                          00119 ; 00016     W := W + B;
 0B3D 18              [2] 00120          clc
 0B3E AD 10F9         [4] 00121          lda    W_
 0B41 6D 10F5         [4] 00122          adc    B_
 0B44 AA              [2] 00123          tax
 0B45 A9 00           [2] 00124          lda    #0
 0B47 6D 10FA         [4] 00125          adc    W_+1
 0B4A 8E 10F9         [4] 00126          stx    W_
 0B4D 8D 10FA         [4] 00127          sta    W_+1
                          00128 ; 00017     W := B + W;
 0B50 18              [2] 00129          clc
 0B51 AD 10F5         [4] 00130          lda    B_
 0B54 6D 10F9         [4] 00131          adc    W_
 0B57 AA              [2] 00132          tax
 0B58 A9 00           [2] 00133          lda    #0
 0B5A 6D 10FA         [4] 00134          adc    W_+1
 0B5D 8E 10F9         [4] 00135          stx    W_
 0B60 8D 10FA         [4] 00136          sta    W_+1
                          00137 ; 00018     W := B + B;
 0B63 18              [2] 00138          clc
 0B64 AD 10F5         [4] 00139          lda    B_
 0B67 6D 10F5         [4] 00140          adc    B_
 0B6A AA              [2] 00141          tax
 0B6B A9 00           [2] 00142          lda    #0
 0B6D 69 00           [2] 00143          adc    #0
 0B6F 8E 10F9         [4] 00144          stx    W_
 0B72 8D 10FA         [4] 00145          sta    W_+1
                          00146 ; 00019     W := S + B;
 0B75 18              [2] 00147          clc
 0B76 AD 10F8         [4] 00148          lda    S_
 0B79 6D 10F5         [4] 00149          adc    B_
 0B7C AA              [2] 00150          tax
 0B7D AD 10F8         [4] 00151          lda    S_
 0B80 09 7F           [2] 00152          ora    #$7F
 0B82 30 02 (0B86)  [2/3] 00153          bmi    2f
 0B84 A9 00           [2] 00154          lda    #0
 0B86                     00155 2:
 0B86 69 00           [2] 00156          adc    #0
 0B88 8E 10F9         [4] 00157          stx    W_
 0B8B 8D 10FA         [4] 00158          sta    W_+1
                          00159 ; 00020     W := B + S;
 0B8E 18              [2] 00160          clc
 0B8F AD 10F5         [4] 00161          lda    B_
 0B92 6D 10F8         [4] 00162          adc    S_
 0B95 AA              [2] 00163          tax
 0B96 AD 10F8         [4] 00164          lda    S_
 0B99 09 7F           [2] 00165          ora    #$7F
 0B9B 30 02 (0B9F)  [2/3] 00166          bmi    2f
 0B9D A9 00           [2] 00167          lda    #0
 0B9F                     00168 2:
 0B9F 69 00           [2] 00169          adc    #0
 0BA1 8E 10F9         [4] 00170          stx    W_
 0BA4 8D 10FA         [4] 00171          sta    W_+1
                          00172 ; 00021     W := S + S;
 0BA7 18              [2] 00173          clc
 0BA8 AD 10F8         [4] 00174          lda    S_
 0BAB 6D 10F8         [4] 00175          adc    S_
 0BAE AA              [2] 00176          tax
 0BAF A0 00           [2] 00177          ldy    #0
 0BB1 2C 10F8         [4] 00178          bit    S_
 0BB4 10 01 (0BB7)  [2/3] 00179          bpl    2f
 0BB6 88              [2] 00180          dey
 0BB7                     00181 2:
 0BB7 2C 10F8         [4] 00182          bit    S_
 0BBA 10 01 (0BBD)  [2/3] 00183          bpl    2f
 0BBC 88              [2] 00184          dey
 0BBD                     00185 2:
 0BBD 98              [2] 00186          tya
 0BBE 69 00           [2] 00187          adc    #0
 0BC0 8E 10F9         [4] 00188          stx    W_
 0BC3 8D 10FA         [4] 00189          sta    W_+1

[BillG]

I made a small "breakthrough" in hacking the TSC BASIC interpreter. The keyword table has finally been identified. It is encoded using the same algorithm as the command table. Each character is doubled, then biased by 26.

No obvious reason for doing this other than hiding the previously disclosed Easter Egg in the command table. It is not faster nor do they save any space in the table.

Code: Select all

 16A0                     03409 L_16A0
 16A0 74 84 8E 84         03410          fcb    'G'*2-26,'O'*2-26,'T'*2-26,'O'*2-26,0,1
 16A4 00 01
 16A6 74 84 8C 90         03411          fcb    'G'*2-26,'O'*2-26,'S'*2-26,'U'*2-26,'B'*2-26,0,2
 16AA 6A 00 02
 16AD 8A 70 8C 90         03412          fcb    'R'*2-26,'E'*2-26,'S'*2-26,'U'*2-26,'M'*2-26,'E'*2-26,0,3
 16B1 80 70 00 03
 16B5 8A 70 80 00         03413          fcb    'R'*2-26,'E'*2-26,'M'*2-26,0,5
 16B9 05
 16BA 7E 70 8E 00         03414          fcb    'L'*2-26,'E'*2-26,'T'*2-26,0,6
 16BE 06
 16BF 86 8A 78 82         03415          fcb    'P'*2-26,'R'*2-26,'I'*2-26,'N'*2-26,'T'*2-26,0,7
 16C3 8E 00 07
 16C6 78 82 86 90         03416          fcb    'I'*2-26,'N'*2-26,'P'*2-26,'U'*2-26,'T'*2-26,0,8
 16CA 8E 00 08
 16CD 72 84 8A 00         03417          fcb    'F'*2-26,'O'*2-26,'R'*2-26,0,11
 16D1 0B
 16D2 86 84 7C 70         03418          fcb    'P'*2-26,'O'*2-26,'K'*2-26,'E'*2-26,0,12
 16D6 00 0C
 16D8 82 70 96 8E         03419          fcb    'N'*2-26,'E'*2-26,'X'*2-26,'T'*2-26,0,14
 16DC 00 0E
 16DE 8A 70 68 6E         03420          fcb    'R'*2-26,'E'*2-26,'A'*2-26,'D'*2-26,0,15
 16E2 00 0F
 16E4 8A 70 8E 90         03421          fcb    'R'*2-26,'E'*2-26,'T'*2-26,'U'*2-26,'R'*2-26,'N'*2-26,0,16
 16E8 8A 82 00 10
 16EC 78 72 00 11         03422          fcb    'I'*2-26,'F'*2-26,0,17
 16F0 6E 78 80 00         03423          fcb    'D'*2-26,'I'*2-26,'M'*2-26,0,18
 16F4 12
 16F5 84 82 00 13         03424          fcb    'O'*2-26,'N'*2-26,0,19
 16F9 6E 70 72 00         03425          fcb    'D'*2-26,'E'*2-26,'F'*2-26,0,20
 16FD 14
 16FE 70 82 6E 00         03426          fcb    'E'*2-26,'N'*2-26,'D'*2-26,0,21
 1702 15

[BillG]

I have been putting some development time into FLEX again.  The first priority is rearranging the several components of the system to arrive at a set of configurations which work on the largest number of dissimilar 6502 systems.

The second is changing the API slightly to try to reduce the reloading of registers.  The initial prototype expected addresses to be passed in registers A:X because that was how I kept a sixteen-bit number while doing calculations.  By changing the calling convention to Y:X, I am saving up to about half of the register reload instructions.

Now I have a couple of questions:

How useful is it to not corrupt memory used by a program if the operating system is rebooted?  Some 680x programs provided a warm restart entry point at $103; this may be useful to try to save data after a crash before a total clean restart.  Is it important at all to preserve the contents of the Utility Command Space under the same scenario?

I have always thought that the "current drive" concept in CP/M and DOS was a much more convenient way to specify the "working" drive than using the ASN (assign) utility in FLEX.

Now that I have a platform for experimentation, I have prototyped a current drive mode for FLEX.  Instead of the usual "+++" command prompt, it uses "0++" when drive 0 is the current drive and operating in current drive mode.  The "1." command makes drive 1 the current drive.

The ASN utility will be modified to switch between the classic and current drive modes in addition to assigning drives in classic mode.

So is this a good idea or am I off in the weeds?

[GARTHWILSON]

BillG wrote:

How useful is it to not corrupt memory used by a program if the operating system is rebooted?  Some 680x programs provided a warm restart entry point at $103; this may be useful to try to save data after a crash before a total clean restart.  Is it important at all to preserve the contents of the Utility Command Space under the same scenario?

I'm not sure how closely this will relate to what you're asking; but if I crash the workbench computer, I can press the reset button, and the boot-up routine puts "New/Old/Init-Ap?" in the 16-character LCD, three options which correspond to three particular keys on the keypad. Pressing the key for "Old" keeps everything I already had compiled in its RAM, rather than starting over. This almost always works because crashes don't usually go writing trash all over RAM, but instead are just from loops whose exit condition never gets met. Init-Ap goes further, and executes the initialization routine whose address is in the init-ap variable. This allows resetting, setting up I/O again, re-initializing things, etc., and being totally back to operational in a couple of seconds, with nothing lost.

[BillG]

On a classic 8-bit machine, crash recovery depends upon how much work I would lose. There was a saying, "Save early; save often."

But the temptation is always there to make "just one more" change before saving.

For maximum chance of recovery if it was critical, I would reboot the OS, mount a blank disk and save all of RAM. A core dump if you will. That gave me a chance for multiple attempts at recovery. Assuming that the act of rebooting does not clear RAM or otherwise corrupt it.

For something less critical, I would just try jumping to the "warm start" address of the application if it had one and try saving. Again to a blank disk so that I do not corrupt the previous good save or saving to a possibly newly trashed disk.

Otherwise, I take a break and then do it over, saving early and often.

[floobydust]

BillG wrote:

I have been putting some development time into FLEX again.  The first priority is rearranging the several components of the system to arrive at a set of configurations which work on the largest number of dissimilar 6502 systems.

The second is changing the API slightly to try to reduce the reloading of registers.  The initial prototype expected addresses to be passed in registers A:X because that was how I kept a sixteen-bit number while doing calculations.  By changing the calling convention to Y:X, I am saving up to about half of the register reload instructions.

Now I have a couple of questions:

How useful is it to not corrupt memory used by a program if the operating system is rebooted?  Some 680x programs provided a warm restart entry point at $103; this may be useful to try to save data after a crash before a total clean restart.  Is it important at all to preserve the contents of the Utility Command Space under the same scenario?

I have always thought that the "current drive" concept in CP/M and DOS was a much more convenient way to specify the "working" drive than using the ASN (assign) utility in FLEX.

Now that I have a platform for experimentation, I have prototyped a current drive mode for FLEX.  Instead of the usual "+++" command prompt, it uses "0++" when drive 0 is the current drive and operating in current drive mode.  The "1." command makes drive 1 the current drive.

The ASN utility will be modified to switch between the classic and current drive modes in addition to assigning drives in classic mode.

So is this a good idea or am I off in the weeds?

First, nice to hear that you're back to working on Flex for the 6502. Second, not sure if my input can help you that much, but here's some feedback.

- Corrupting memory. I've been using DOS/65 for quite a while now. I have found that it does not corrupt anything in the TEA area on a reboot. In short, I can exit DOS/65 to my Monitor using the GO command or simply hit RESET on the SBC. Entering DOS/65 again results in no memory overwrite in the TEA area... I can simply use the GO command and re-enter the program loaded in TEA and all is well.

- Utility Command Space... not sure on this one, as I'm not familiar with Flex. DOS/65 uses $100 as a warm boot and $103 as the entry to PEM. Of course, these only survive if you don't overwrite memory when rebooting the system.

- Active Drive. As CP/M used letters for drives (as did DOS and later MS OSes), it's a familiar prompt for CLI. Again... with DOS/65, the current version supports multiple users, so the default prompt shows ">A0" for the A drive and the default User 0. Change the User to 1 and the prompt changes to ">A1". Maybe this would be something to consider??

In any case, I'd be happy to try a version of Flex when you have it ready. As previously mentioned, my SBC has a Compact Flash interface and the BIOS uses 24-bit LBA access for Read and Write.

[drogon]

BillG wrote:

How useful is it to not corrupt memory used by a program if the operating system is rebooted?  Some 680x programs provided a warm restart entry point at $103; this may be useful to try to save data after a crash before a total clean restart.  Is it important at all to preserve the contents of the Utility Command Space under the same scenario?

It was handy for me when developing my BCPL VM to look at RAM sometimes after a reset, so I added stuff into my RubyOS to let me dump RAM to screen (as well as dump the current BCPL VM registers, but that's an application specific thing).

Also, in addition to that, I added in code to deliberately wipe RAM to a known pattern so I could wipe/fill RAM, then run up my BCPL VM, then if it crashed or went AWOL I could check to see if it was scribbling over bits of RAM it wasn't meant to. (The default was to put pattern in Bank 0, Pattern+1 in Bank 1, and so on for the 8 banks of 64K in the '816 system) The fill thing was handy to check that something wasn't expecting a particular value either - so it was easy to find something that worked most of the time, then fail at other times - if that something was expecting RAM to be zeros for example - ie. to make sure my code initialisations was working correctly.

-Gordon

[BillG]

drogon wrote:

It was handy for me when developing my BCPL VM to look at RAM sometimes after a reset, so I added stuff into my RubyOS to let me dump RAM to screen (as well as dump the current BCPL VM registers, but that's an application specific thing).

Most 680x computers start up in a monitor in ROM following a reset. They generally provide rudimentary debugging facilities such as viewing and changing memory and register contents.

Some 6502 computers do but many do not since they are oriented toward people using them as a tool rather as an end in itself.

[BillG]

floobydust wrote:

First, nice to hear that you're back to working on Flex for the 6502. Second, not sure if my input can help you that much, but here's some feedback.

I felt like I needed to spend some time actually using it and programming for it to know how well early design decisions worked out and I am glad I did that instead of having to release a different and incompatible second version.

floobydust wrote:

- Corrupting memory. I've been using DOS/65 for quite a while now. I have found that it does not corrupt anything in the TEA area on a reboot. In short, I can exit DOS/65 to my Monitor using the GO command or simply hit RESET on the SBC. Entering DOS/65 again results in no memory overwrite in the TEA area... I can simply use the GO command and re-enter the program loaded in TEA and all is well.

Many versions of FLEX on the 680x corrupt all or parts of the address space when determining how much RAM is installed. It is not that much harder to do so nondestructively. The issue is how to structure the OS bootstrap code to disturb as little as possible and what in particular to preserve.

floobydust wrote:

- Utility Command Space... not sure on this one, as I'm not familiar with Flex. DOS/65 uses $100 as a warm boot and $103 as the entry to PEM. Of course, these only survive if you don't overwrite memory when rebooting the system.

The UCS is a 1.5K area set aside within the system image for the purpose of loading and running system commands which are relatively small utility programs. I am working out a scheme to minimize the amount of space the bootstrap code permanently takes away from the available RAM after the system is up. The job is much easier if I can trash the UCS area during startup.

floobydust wrote:

- Active Drive. As CP/M used letters for drives (as did DOS and later MS OSes), it's a familiar prompt for CLI. Again... with DOS/65, the current version supports multiple users, so the default prompt shows ">A0" for the A drive and the default User 0. Change the User to 1 and the prompt changes to ">A1". Maybe this would be something to consider??

The customary FLEX prompt is "+++" and after invoking current drive mode, it becomes "d++" where d is the current drive number.

I hated the CP/M user number concept, particularly the need to keep multiple copies of programs differing only in the user number. CP/M Plus (version 3) made some changes so that user numbers worked better, but I do not have much experience actually using that.

floobydust wrote:

In any case, I'd be happy to try a version of Flex when you have it ready. As previously mentioned, my SBC has a Compact Flash interface and the BIOS uses 24-bit LBA access for Read and Write.

I have some questions for you in particular.

My tools can generate both Motorola and Intel hex files. Does your ROM burner allow hex files in which the load addresses jump around, meaning not in ascending address order? I do not have and will not be using a linker. The ultimate goal is to eventually be able to build and configure FLEX natively on a FLEX system. The 680x way is to build the several components ORGed at non-overlapping addresses, then concatenating the resultant binary files.

Have you given any more thought to how to get files into and out of the system? I still think that a way to image a partition of your CF card from or to a virtual disk in a file would be the easiest to use.

[floobydust]

Thanks for the detailed reply... very good and informative.

I use a Dataman 40Pro Programmer... it will handle a wide variety of formats including Intel Hex, Motorola S-Record, binary, etc., so I think it should handle anything you can generate, including non-contiguous data. I currently load 3 different S-Record files into the software, then program the EEPROM. The code pieces are separate and include the BIOS, Monitor and DOS/65 modules.

As for moving data to the SBC, my Monitor can send and receive binary data via XMODEM-CRC over the console port. On download, it will automagically sense and decode Motorola S-record (S19) files on the fly. I can also specify an offset address, which allows me to download binary code for a ROM address range to a specified RAM address. This is handy, as I can update EEPROM code without removing the EEPROM, as my Monitor also provides the ability to program the EEPROM insitu.

I've since written a separate Flash Utility which can update the Monitor code insitu. I've got an early version Flash Utility for the BIOS, but that one is more tricky... it works, but doesn't reset the SBC... just goes into neverland forcing a hardware reset to get it back.

[BillG]

I had previously reported that Corsham Technologies was selling reproductions of SWTPC computer components. They have also produced a CPU board based on the 6502 to plug into the same types of systems.

Sadly, Bob Applegate passed away about a year ago after a long fight with cancer. I had never taken advantage of the opportunity to buy from him.

Frederic Brown, founder of Peripheral Technologies, has begun producing sort of replicas of some of the Corsham products. He is mostly a fan of 680x computers, so it is not likely that he will provide KIM or SYM products, but much of the SWTPC stuff is now available again along with his own line of .SWTPC reproductions.

https://peripheraltech.com/

I find his improved design for the 6502 CPU board very interesting. The SWTPC bus is generally limited to memory cycles at 2 MHz. His design runs the 6502 at much faster clock speeds along with ROM and RAM on the board to support that speed. Wait state circuitry makes the board compatible with the slower SWTPC bus speed.

BTW, I have been collaborating with Frederic. He has been able to run some of my 6502 code on his board. We are currently working to bring FLEX up on it.

[floobydust]

Most interesting... is there a version of Flex that I could try to port to my 65C02 system? I'm now using a RAM based DOS/65 version that boots from an IDE drive. There is currently 56KB of contiguous RAM.

[BillG]

Unfortunately, I still do not have anything distributable, especially for adaptation to different hardware.

The current effort is to migrate to a new reference platform based on the upcoming Peripheral Technologies hardware.

Also,

* the API is still not totally nailed down
* you have expressed a desire to have FLEX reside in ROM
* a long-term goal is to eventually be able to walk a majority of well-behaved programs written for 6800 FLEX, so some research is still needed