TheBF

July 14, 2020

On 7/4/2020 at 1:44 PM, Vorticon said:

This looks super interesting. I dabbled with text adventures previously, and the biggest challenge at the time was creating a natural language parser instead of the usual 2 word commands. [ Eons ]

NPC's add a nice element to any adventure, assuming they are smart enough. Looki g forward to your progress!

That's a very nice looking game. I never played these games when then were popular so it's all new to me.

Did you keep all the text in RAM or was there a separate file of text phrases to draw on?

July 12, 2020

2 hours ago, acadiel said:

I think that in the spirit of Omega's original question - creating transparency for the user is probably the key first and foremost.

In XB, RXB, SuperXB, etc, those can likely be modified to where you type SIZE, you get a whole hunk of memory that XB can handle from SAMS (including the 32K space at >2000 and >A000). I know RXB has a lot of that support for SAMS already. Depending on the availability of XB and SuperXB source (Triton SuperXB, the German Silver and Gold carts, etc), we might or might not be able to modify those if people want to use different varieties.

Turboforth, from what I read above, seems to support SAMS.

Assembly is a little more challenging. You are already programming bare metal, and a lot of coders have their own subroutines already made that they include in their programs. If you're used to doing that, for a "beginner to immediate" skilled assembly programmer (which would be me), I'd like to have some standard types of subroutines for SAMs that I could easily call already written - I just stick them in my program. Expert assembler programmers like Tursi, Mark Wills, and others write their own optimized code and know how to optimize every single last bit for brevity and performance, and likely already have some subroutines in their code we could use (if they're programmed for SAMS yet). You can see some rudimentary bank switching "trampoline" type routines in the source code for 16K and above ROM carts. John Phillips' The Great Word Race, Strike III, StarGazer I/II/III Combo cart, and others have source on WHTech that have some of his bank switching code. He had two types of bank switching code routines: CRU and "Write to ROM", and he reused the same code in his assembly for those types.

As far as native OS support - for the basic console to be able to recognize something above >FFFF transparently, the GROM/ROM in the console would have to be overridden by OS code that knows how to bank/handle transparent access to those addresses, such as >10AAA. And I'm guessing E/A and some other programs would also need to be patched, because they're used to the 64K memory map. Since the 9900 hardware likely doesn't support it, the software layer will have to translate to the 64K "window" so the 9900 can do whatever it needs to. I'm sure other 16 bit consoles are out there that figured out how to break out of the 65536 bytes of RAM by paging. I just don't know what they are.

I'm sure I simplified things way too much or didn't use completely correct info above - I'll let the more seasoned developers correct me as needed

I think your request in very reasonable. It does not take very much code to allow you page in a 4K block on demand somewhere and you can pack a lot of code into that space.

July 12, 2020

I am noodling how to do the mapping the fastest way.

I am thinking of storing the SAMS pages as integers so I don't have to swap anything and using literal addresses for the SAMS registers.

CODE CSEGMAP ( page# -- ) \ Page # format:  xx00
      R12  1E00 LI,    
           0SBO,       
      R4+  401A @@ MOV,    \ R4 is TOS 
      R4+  401C @@ MOV, 
            0SBZ,              
      NEXT,
      ENDCODE

Is this optimal?

Edit NO. This is wrong. I can't auto-inc R4. I have to add >0100 to get the next SAMS bank with this method.

July 12, 2020

3 minutes ago, jedimatt42 said:

My SAMS based heap and stack management doesn't exist yet... it's be like a standard C malloc library... with a management function to add or release pages into the heap. Moving the gcc stack into SAMS would slow things down quite a bit... as you'd have to replace all the mov blah,*r10+ to not do the + and then do bank boundary checking... Since the eco-system I'm thinking of has a gcc base system, that then loads overlays, it could gain usable memory without performance issues, by just paging the stack out completely when initializing an overlay. That way the overlay can choose how the address space is divided between stack and heap.

Ok. Sounds familiar. I used the DIV instruction to do boundary checking. I divide a 32bit address ( Whatever type that is in C) by >1000 and the results give me the SAMS page and an offset which I add to the RAM address where the memory is mapped. It sucks to do division for memory locations so I try to limit it to record sized accesses.

Lee Stewart took a run at doing it with other instructions to remove the DIV, but the nature of the 9900 meant that more instructions netted out to the same speed as DIV, from I could measure.

I am looking at making a "CSEG" that uses two sequential 4K pages at D000 & E000. I will simply pull in 8K of SAMS just for code so that I can get a bigger block of code paged in. Not sure if that's a better idea but it would mean I would have 8K overlays instead 4K as I have now.

All this discussion is probably giving Omega-TI a better idea of the challenges we face in using SAMS memory.

July 12, 2020

1 minute ago, jedimatt42 said:

We already have TurboForth, that includes a module to naturally program in forth and just have your code load into extended banks of SAMS. You have to specify the banks, but you don't have to write the code very differently.

Then there is the way I write GCC C code for banked switch cartridge space... I will eventually abstract that to SAMS, along with sams based heap and stack management. This will probably fold into what I do in force command when I get to supporting overlay programs.

I did some independant work to allow the Camel99 compiler to emit code into SAMS pages as well. I limit it to 4K pages of code and the Forth dictionary is the selector. So you have to explicitly select the 4K module you want to use. It's workable and extends how big you programs can be for sure. The last piece I need is to create the linked list of modules so it appears more contiguous. I remember seeing Willsy's code a few years back. It seem like more than I wanted since I don't have the system in a cartridge.

Can you explain a bit about your SAMS based heap and stack management or point to a code repository?

July 12, 2020

29 minutes ago, Omega-TI said:

From my limited understanding, it's probably not possible due to design, but it would be so cool if there was a way to attach some sort of aftermarket controller to the SAMS card to sense and manage all the memory stuff transparently by size.

It is the panacea that everybody wants for sure.

I think you would have to re-design the machine but then you have no software.

July 12, 2020

I have been fighting with the best way to use the SAMS card too. I ended up using one 4K page in the native space at >3000, a BANK# variable to remember which bank is in memory like a single entry page table.

I have a function that only maps in a block if it's not resident already. Since 1M byte needs a 20bit address I created a "segment" variable for the extra bits and directly reference memory in 64K segments. Memories of DOS.

It works pretty well if I treat it like blocks of memory. As long as I don't cross block boundaries its just like regular RAM.

I can operate on bytes and words and it's not too bad but nowhere near as fast as normal, when every access requires a decision but it works.

It has occurred to me recently that I might be able to keep a little multi-tasking kernel at >6000 and keep completely separate memory spaces at 2000...3FFF and A000 ... FFFF by blitting numbers into the SAMS registers on each context switch. That would make a small multi-user system . With a console task running over RS232 it would be possible to load programs into another context space. That could be fun.

July 11, 2020

20 minutes ago, Tursi said:

Sorry for the AMS hassle. The current core of Classic99 requires me to pre-init the AMS registers, and it has bitten numerous people. But remember - you should always initialize all registers of any hardware you're using - don't assume someone else did it. Then you know your software will always work.

"And still I am learning..."

Michelangelo

July 9, 2020

After trying out a new editor that I have been working on Vorticon suggested that I open a topic for the benefit of the greater group.

Somebody may find it useful. The ability to copy files and lines and paste them into a new composite file is pretty handy or cut a file up into separate files.

It uses key commands for editing and the command line for saving and getting files. DIR and CAT commands are available within the editor because I have a good memory but it's short.

ED99-40 column Beta Release 1.1

40 column multi-file editor

Changes:

V1.1 built on "new and improved" Camel99 Kernel (thanks Tursi)

Fixed problem: SAMS card was not initialized on startup. Worked on Classic99 failed on real hardware.

Clipboard uses the upper end of SAMS memory so 511 lines can be copied.

Fixed the ED99CONFIG file to use DSK1. to find the font to load.

Four font files have been included with the release.

Feature Additions

FCNT 4 (break) will stop file loading. The partial file will be in SAMS memory. Use PURGE if you don't want to keep it
FCNT 4 (break) will stop file save. The partial file will be written to disk.
CTRL A will copy entire file to clipboard.
CTRL P will paste entire file to the END of the current file. (Insert can be too slow at this time)
Number of lines in clipboard is displayed on lower right side of editing window
PRINT command prints the active file to any DSR enabled device.
- Examples:
  - PRINT PIO
  - PRINT RS232.BA=9600
  - PRINT CLIP (Classic99 only)

Limitations

File size is still limited to 511 lines

Inserting to the top of a large file is still slow due to the simple internal data structure.

Future

80 Column version and SAMS memory are not playing together nicely. Not sure why yet.
Single level undo/redo
Document user level editor commands for DSK1.ED99CONFIG

Bugs from Vorticon's Beta test

Pressing <ENTER> after the first line inputted moves the line down and the cursor is positioned above it. It is not possible to enter text below that first line. Is this a feature or a bug?
Pasting with Ctrl-P pastes the contents of the clipboard after the End of File marker and adds yet another End of File marker. I would have thought that the pasted text will appear just above the EOF marker...
- This should be fixed now. (off by one error...)

Below are the contents of the readme file.

By the magic of Classic99, in the ED99 command line I typed PRINT CLIP and pasted this into the browser. Pretty cool.

README for ED99 Editor Brian Fox July 2, 2020

ED99-40 is a text editor for the TI-99 COMPUTER

It requires the Editor/Assembler cartridge.

Starting ED99-40
- To start the program select menu option 5

- Place the ED99-40 files on a disk and place it or mount it as DSK1.

- At the RUN PROGRAM FILE prompt type:
DSK1.ED99-40

=============================
There are 10 files in this package:

README.TXT (this file)

ED99-40, ED99-41, ED99-42
The 3 binary files of the editor.

ED99CONFIG
A DV80 text file with editor commands to
setup the editor the way you want it .

*Type EDIT DSK1.ED99CONFIG to alter the file.

ED99DOC
A simple list of the key commands and text commands that control the editor

FONT FILES
- FONT0230 Default font loaded at start up
- FONTEDT1 Same font use by EDIT40 V3 of the TI E/A editor
- TI99FONT The standard font used by TI99 BASIC
- FONT004 Alternative font with correct descending lower case letter

Contact info:
I am commonly available on Atariage.com in TI-99 development forum as theBF.

ED9940.DSK.zip

July 9, 2020

2 hours ago, Vorticon said:

You really should create a separate topic for this so the rest of us can more easily follow updates

Good point. I will do that.

July 9, 2020

1 hour ago, Vorticon said:

So a couple of things I noticed with ED99-40:

Pressing <ENTER> after the first line inputted moves the line down and the cursor is positioned above it. It is not possible to enter text below that first line. Is this a feature or a bug?

Pasting with Ctrl-P pastes the contents of the clipboard after the End of File marker and adds yet another End of File marker. I would have thought that the pasted text will appear just above the EOF marker...

Otherwise it seems to work great. I still have to test the print function on real hardware though.

These are bugs. I am the ctrl P fixed. Need to re-work the logic for Enter when at end of file.

I am interested in that print function. It's nothing special because it just uses the DSR so it worked find on real hardware with RS232.BA=9600

PIO should work the same.

Thanks for the update. 80 column version is working. Will get something out tomorrow for you I hope.

July 8, 2020

It's never a good idea to give your TI-99 extra work to do.

Tursi helped me find a big error in my kernel code for the execution code for variables, user variables, constants and DOES> words.

I went back to see the effect of not asking the system to do the extra instructions I had mistakenly made them do.

Here are two simple benchmarks the really improved: ( confirmed them with a stop-watch because I didn't believe it either)

HEX 
VARIABLE X
: BENCH6  ( -- ) 7FFF 0 DO   X @ DROP  LOOP ;
\ Camel99 Forth
\ Version  v2.5     v2.62b
\ Seconds  7.6       5.5

\ Camel99 Forth
\ Version  v2.5     v2.62b
\ Seconds  7.1       5.4
: BENCH7 ( -- )  7FFF BEGIN  1- DUP  0= UNTIL ;

This larger benchmark improved but not as much:

\ Camel99 Forth
\ Version  V2.5  2.62b
\ Seconds  26.4   25.73

INCLUDE DSK1.VALUES

5 CONSTANT FIVE
0 VALUE BVAR
HEX
100 CONSTANT MASK
: BENCHIE     
         MASK 0
         DO
            1
            BEGIN
              DUP SWAP DUP ROT DROP 1 AND
              IF FIVE +
              ELSE 1-
              THEN TO BVAR
              BVAR DUP MASK AND
            UNTIL
            DROP
         LOOP ;

This version of the Sieve of Erathosenes improved nicely and actually is a touch faster than my previous Turbo Forth test.

This is also because in V2.6 I made HERE a code word.

Spoiler


\ Sieve of Erathosenes in Forth

NEEDS ELAPSE FROM DSK1.ELAPSE

: [@] ( n addr -- c)  + C@ ;
: [!] ( n addr -- )   + C! ;
: ERASE  ( addr n -- ) 0 FILL ;

HEX
: FREEMEM  ( -- n) FF00 HERE - ;
: ?MEM     ( n -- )  FREEMEM OVER < ABORT" Out of memory" ;

: SEEPRIMES ( -- )
        CR ." Primes: "
        2 DO
            I HERE [@] 0= IF I . THEN
            ?TERMINAL ABORT" Primes halted"
        LOOP ;

\ byte array uses unallocated memory at HERE
DECIMAL
: PRIMES ( n -- )
        ?MEM
        CR ." Running " DUP U. ." primes"
        HERE OVER ERASE
        1 0 HERE [!]       \ mark as prime like 'C' version
        1 1 HERE [!]
        2                  \ start at 2
        BEGIN
           2DUP DUP * >
        WHILE
           DUP HERE [@] 0=
           IF  2DUP DUP *
               DO
                  1 I HERE [!]
               DUP +LOOP
           THEN
           1+
        REPEAT
        CR ." Complete."
        .ELAPSED
        CR
        DROP
        CR ." Press ENTER to see primes:" KEY 13 =
        IF   SEEPRIMES   THEN
;

: RUN  10000 TICKER OFF PRIMES ;
\ Manual stop watch timings
\ Turbo Forth      7.9
\ Camel99          
\ V2.0             10.3 
\ V2.55            8.2
\ V2.62b           7.6
\
\ Camel99 DTC      7.2

July 8, 2020

I have read that there are only two hard problems in computer science.

Memory, naming and off by one errors.

This problem was of course me.

Forth cross-compilers are very manual. A few of the key routines must be used before they are coded.

This means the programmer has to fill in their missing addresses later. (resolve forward references)

I was off by one memory word...

All the code generated by the compiler was correct. The human adjusted part... not so much.

I guess I shouldn't feel too bad about having my a*s handed to me by the Harmless Lion.

Thanks again Tursi for showing me the error of my ways.

(Now that the system is not running those extra nonsense cycles I gave it, it's even faster. )

July 8, 2020

I think my finger error was why it didn't break on >A070.

I didn't regain focus on the Forth console window when I hit enter so of course it did nothing.

Thanks again for this excellent emulator.

July 8, 2020

The extra indirection did not work out of the box.

Thanks for your patience and all your help.

July 8, 2020

Just now, Tursi said:

Well, it's pretty clear in your screenshot. R5 contains >A070, and your last executed instruction that uses it is B *R5. The trace shows that >A070 was executed, it even tells you how many cycles it took. You insist that >A070 is not supposed to be executed, it's supposed to be a pointer to the function at >A072. I know how to read the debugger I wrote, and I know 9900 assembly.

I also know this particular trap is easy to get screwed up on, as I just spent a full month fighting it in my music player. The 9900 doesn't do indirection intuitively, that extra lookup is needed.

Anyway, I've explained the debug message. I've analyzed your code. But until you try the suggestion that's enough work on my side.

I believe you completely.

I will build a new one right now.

July 8, 2020

4 minutes ago, Tursi said:
Well, Classic99 won't disassemble data statements, only statements the CPU has executed, so that helps.

Your breakpoint is on /access/ to >A070, not execution... put no prefix at all on it.

That said, the execution trace clearly shows that >A070 was executed as an instruction. You need to be starting your function at >A072.

From the code that's posted, I guess these are the lines in question:
838A  C239  mov  *R9+,R8          * Forth interpreter  *IP+ -> W
838C  C178  mov  *R8+,R5          * *W+ -> temp
838E  0455  b    *R5              * branch *temp
So in >838A, R9 was B284 -- we can't see what is there, but we know that it dumped it into R8 and must have got >AA86

We then moved from AA86 into R5, then jumped to it.

We can see that R5 is indeed >A070.

Assuming the first two statements are correct, I think you probably meant to have one more indirection there:
mov *R8+,R5     * *W+ -> temp
mov *r5,r5      * get function pointer from temp
b *r5           * and branch to it

Your breakpoint is on /access/ to >A070, not execution... put no prefix at all on it.

When I put no prefix on >A070 it does not break.

But when I set it for >A072 , No prefix, it stops.

Here is the code that was running. It is a low level routine to write a character to the screen.

The thing it is doing at the break point is getting the address of VCOL, the video column "workspace" variable.

I don't think another indirection will work. This is the same interpreter used by FbForth and TurboForth and is a direct translation of the formula written up by Brad Rodriguez in moving forth. The 9900 is almost the perfect instruction set to write his example so it's pretty straightforward.

In the screen capture you can see the "list" of addresses that are run by the interpreter.

They begin at >B280

839E is the address of "enter" a list of addresses

A812 is the address of VPUT, assembler primitive to put a char on the screen

AA86 is the address of VCOL, which we are trying to understand.

I also decompiled (EMIT) so we could verify that the second address is the workspace variable in question.

Just tell me when to stop. I am enjoying the discussion but everything works fine.

July 8, 2020

I set the breakpoint at >A070 and pressed enter. This of course cause the "ok" prompt to be processed and so a call to my VSBW was needed.

Here is the full dump with comments to explain some internals to Camel99 Forth.

You can see a second example of the pointer to code at A080 in the dictionary structure.

It is a wicked mix of code and data so I have no idea how you would differentiate them.

Originally I had the two pieces of code swapped in memory and so my console was reading the cursor variable all the time and the "pointer"/code at >A070 ran continuously and I could see it traverse the memory in the heat map.

But as mentioned, it is not code. It is data. I have not checked every assembler word in the system but they all live from A000 to A97E so a lot of the pointers will look like variations of the add instruction. I have watched some of the others execute so it's consistent.

And if it just a side effect of this weird language in Classic99 that's fine. I am just always unsure of my homemade compiler.

A758  06C0  swpb R0                * piece of VDP write address setup
A75A  0300  limi >0000             * disable interrupts
      0000
A75E  D800  movb R0,@>8c02
      8C02
A762  06C0  swpb R0
A764  D800  movb R0,@>8c02
      8C02
A768  045B  b    *R11             * return from VDP write setup
A830  06D6  swpb *R6              * character is on the stack
A832  C836  mov  *R6+,@>8c00      * write to VDP
      8C00
A836  0300  limi >0002            * Just like Tursi said :)
      0002
A83A  C136  mov  *R6+,R4          * refill top of stack cache register
A83C  045A  b    *R10             * return from VSBW
838A  C239  mov  *R9+,R8          * Forth interpreter  *IP+ -> W
838C  C178  mov  *R8+,R5          * *W+ -> temp
838E  0455  b    *R5              * branch *temp
A070  A072  a    *R2+,R1          * !!!NOT CODE!! POINTER TO CODE
>  A072  0646  dect R6            * make room on stack
A074  C584  mov  R4,*R6           * push TOS cache onto stack. R4 now free to use
A076  02A4  stwp R4               * get the WP register into R4
A078  A118  a    *R8,R4           * *R8 holds offset of workspace variable. Add to WP
A07A  045A  b    *R10             * branch to Interpreter, >838A through R10
* next forth word definition in "dictionary"
A07C  A069  a    @>0005(R9),R1    * DATA: link to previous Forth word
      0005                        * DATA: IMMEDIATE BYTE, STRING LENGTH
A080  444F  szc  R15,*R1          * TEXT: "DO"
A082  5641  szcb R1,*R9           * TEXT: "VA"
A084  52FF  szcb *R15+,R11        * TEXT: "R", FF (alignment byte)
A086  A088  a    R8,R2            * DATA: Pointer to code (like A070)
A088  0646  dect R6               * make room on stack
A08A  C584  mov  R4,*R6           * push TOS register
A08C  C108  mov  R8,R4            * Get address of a variable -> TOS

July 7, 2020

4 hours ago, Tursi said:

Okay, I understand what you are saying, but you didn't provide enough of the software for us to analyze the problem.

Put a breakpoint at >A070, and then you can see a trace of exactly how it got there. That usually solves the question.

I put it there.

The Forth compiler lays down a pointer to code as the first word in a routine. In the case of an assembler routine the pointer points to the next 16 bit word which where the machine code is.

In this case the pointer address >A072 happens to also be the instruction: A *R2+,R1

I will get you the entire code and a memory dump as well. Standby...

July 7, 2020

5 hours ago, Asmusr said:

What is the value of R2 at >A070?

It's random. I am not using it at that point.

It is for VDP routines typically.

But if I put one these workspace variables in a loop it will just increment endlessly.

July 7, 2020

3 hours ago, Tursi said:

Didn't we go over this in another thread some time ago?

So first off - assume that the reported PC might be late - it's reporting the program counter when the access happens... there's a good chance the instruction was already parsed and the PC incremented. Looking at the code, we can see that >A072 is unlikely, but >A070 looks pretty likely.

So is it right? Is the interrupt mask 2 when VDP is read at >A070? That's all the warning is telling you.

"There seems to be no side effects"... when you access the VDP with interrupts enabled, then 60 times a second there is a chance that the console interrupt will take control and potentially corrupt your VDP address. If your code takes a full millisecond to execute, then pure chance says that 15 times out of 16 it will run just fine. The nature of software when the VDP address unexpectedly changes means that there's a good chance you won't even notice as the end user about half the time, so now we're saying you won't notice at least 30 times out of 32. Most access blocks are faster than a millisecond, meaning the odds of actually being hit are even smaller. But race conditions are bad, and eventually, they always get hit.

The warning is in the emulator because it's bad practice, and you probably shouldn't do it. But if you do do it, then don't blame the emulator if it breaks - whether it breaks in emulation or on hardware.

Of course, as implemented the warning isn't perfect. It doesn't check whether the VDP interrupt bit is enabled in the VDP for instance. It probably could also check the console interrupt control flags - I think if you turn off all the built in routines it's probably okay. But it's just safer to protect your VDP access. For a sense of what happens when you don't respect the interrupt, go look at some of the ColecoVision threads. On that machine the VDP interrupt is non-maskable, so pretty much every new programmer runs into strange corruption issues, and ends up working around them with sleeps and fragile balancing acts, hoping to win the race every frame.

But it's just a warning.

We did talk about it and I changed all my VDP routines and they never make trouble now.

This is different.

What seems to be happening is somehow the DATA at >A070 is executing even though it is NOT code. It is DATA, a pointer to the next address. This is a function of indirect threaded code.

And because the DATA looks like an Add instruction that auto increments R2, it will randomly hit the VDP ports as R2 increments along through the memory.

BUT... it should never be executed. It is not code. It should never be executed.

So I can't figure out how to tell is it me or you.

My sense is that if I had it wrong then the entire Forth system would collapse into a pile of schist because the whole thing is running by using this indirect threading mechanism.

July 6, 2020

I can't figure this out.

I get this debug warning:

Warning: PC >A072 reading VDP with LIMI 2

When this code runs:

******************************************************
* Warning: PC >A072 reading VDP with LIMI 2
******************************************************
A070  A072  a    *R2+,R1      * THIS IS A POINTER. but the code runs
A072  0646  dect R6           * THIS IS CODE THAT RUNS  
A074  C584  mov  R4,*R6         
A076  02A4  stwp R4             
A078  A118  a    *R8,R4         
A07A  045A  b    *R10         * branch to Forth interpreter

* The Forth interpreter when the above is interpreted 
838A  C239  mov  *R9+,R8      * POP Instruction pointer (A070) to R8 w/autoinc
838C  C178  mov  *R8+,R5      * move contents (A072) of R8 to R5, w/autoinc
838E  0455  b    *R5          * branch to the code address (A072) in R5

Explanation Note:

The code at >A072 is computing the address of a "workspace" variable. ie: a variable that is referenced with the WP register so that difference contexts can have the same variable name but with unique values. I got the same results when a simple variable ie: a routine that simply returned an address to R4, occupied this address space >A070.

I have also now seen that this is occurring in all the Forth routines because they all use this indirect interpretation method. The difference is that the value >A072 is incrementing R2 so if put in a loop it will touch every address.

There seems to be no side effects except the error message. I see no problems on real hardware but I don't have the tools to see the CPU in such detail on the TI-99.

One Canadian penny for anyone's thoughts. Oops, we don't have pennies anymore.

Ok 5 cents then.

July 5, 2020

You driving it with the TI-99 … right?

July 4, 2020

I'm feeling your pain all the way up here.

There must a refreshing beverage of some kind in your state to ease your pain for the 4th of July.

Hope you can stay cool enough. It's hotter than hades up here the last few days. (88+ F)

July 3, 2020

ED99-40 column Beta Release