Here are the latest news regading my #TMSnake #game for #rc2014 and #TMS9918a #graphics.
The video below shows the current state of affairs, and I've just added some limited #sfx to the game - however the recording below did not capture the beepy beeps for some reason.
There is one last tweak I need to add in terms of gameplay but the final release is "coming soon" 
Update on #dxbbs which now allows the user to enter multiple lines of text until enter is pressed on an empty line.
The text is stored in a temporary ASCII file, line by line. This will later allow for additional line editing before saving - at least that is what I plan to do.
The final message is appened to the message base file and a new index record is written as can be seen in the screenshots.
For those of you who are interested in my latest project, #dxbbs you may like to know that I've done some code cleanup, renamed existing variables and introduced new ones, especially for the message base files. this is in preparation of handling multiple message bases.
I've also implemented "message flagging/unflagging" in combination with the msg_purge routine. The latter takes some time to process all messages since it actually creates a re-indexd copy of all files for the selected message base.
So I thought it would make sense to "flag" messages for deletion, effectively excluding these from being listed or read and then have the option to physically delete them and re-arrange the message file during a maintenance window, where there is enough planned downtime for such an action.
Let me note that the code is by no means an example for proper #forth programming. I'm not there yet, but in case you are interested, here's the link:
https://gitlab.com/ufud-org/rc2014-dxforth/-/tree/main/bbs?ref_type=heads
if you are interested in the various drivers and programs I've so far written in #DXForth for the #rc2014 computer running the CP/M #cpm operating system, I'd like to remind you of the code repo I've put up recently. Documentation is rare, to say the least. But all the code is there:
... another update on the progress with DX BBS. Today, I've updated the input routine so that it is now capable of:
1.) input length limitation ( it is not possible to enter more than 'n' characters, halting cursor movement at 'n')
and
2.) a basic mechanism of "hiding" the input instead of echoing it
these two features are implemented in one #Forth word which ( in the example screenshot ) is being called like this:
#16 #1 bbs_input | Stack: ( ulen uhide -- )
so you can enter a max of 16 chars and these will be "hidden". It's a more basic routine similar to "instr()" in #RBBS4. I use the return stack to store the length and hide-flag which works since the loops in the word definition are *not* counted (do..loop). Boy do I feel clever ... heh ... 
A quick update on the ominous "DX BBS" (I think the name is beginning to sink in) project of mine: yet another milestone!! 
No fancy video or screenshot this time but rest assured that I now have a 'copy_msg' function which will copy any random message from the message base to a new set of message and index files.
This means that I can now cherry-pick a selection of messages to be copied or exclude a single message from the rest of the records to be copied. Best thing: re-indexing the (new) message index comes for free ...
Looks like my initial design for the message base system pays off - yaaaay!
I need to do some more testing but things look good at the moment.
Work is slowly progressing on the core code of what I still call "DX BBS" until I find more suitable name for it.
Today I've added a session timeout counter that will disconnect after approx. five minutes of inactivity. No RTC required, which is nice (I have plans to write a driver for the DS1302 RTC module for RC2014 sometime in the future, but this is not a priority right now).
Message posting, listing and reading works on a POC level but needs further refinement.
Especially deleting messages and re-writing the corresponding data files is the next milestone I set for myself.
*If* the message base system turns out the way I imagine, there's a good chance the final program will be able to serve whatever line width your client can handle (32, 40, 80 ... columns) - wouldn't that be nice?
Milestone!
Now the core code for writing, indexing and reading messages works. It needs a lot of fine tuning, but the screenshot below is proof that my concept for the message base file is working.
#RetroCoding
#RetroProgramming
#BBS
#rc2014
#DXForth
#Forth
#CPM
... an update from the trenches:
the code snippet which has been loosely resembling #BBS core functionality (the one I once wrote in #DXForth) has seen a few updates recently.
so now "DX BBS" is able to read and output ASCII text files (it could only read #Forth screen blocks before).
I've also fixed several issues where a connection drop would sometimes allow the next caller to "capture" the previous session.
Next on the list will be the whole "post-a-message" process: writing an index file entry for each new message and storing the corresponding message text etc.
long distant future design goals (so far):
(+) implement DX Forth SIO/2 driver
(+) implement a stable (disconnect proof) BBS program loop
(+) stay true to pure ASCII output only, no fancy escape squences or colors - just like RBBS / RCBBS do
(+) implement text (ASCII) file output
(-) store BBS configuration in plain ASCII text file
(-) implement mesage posting procedure
(-) implement message reading procedure
(-) implement message maintenance procdure (delete msg.)
(-) implement user database
(-) implement user database maintenace procedure (delete / modify user)
(-) implement simple user ACL / flag system
(-) implement (x)modem transfers
I don't have a real roadmap, my motivation may vary and the above is just what I think are the minimum requirements for a classic CP/M based bulletin board system. To give you an impression: it should resemble what #rc2014 #rcbbs does at the moment.
#rc2014
#cpm
#retrocoding
#forth
#bulletinboardsystem
#funwithforth
Recent and very sad events made me turn my attention to another project of mine, one I had shelved for too long.
I know I've shared a similar video some time ago, but this time some of the more obvious glitches have been fixed.
So here is another demonstration of a 7 screen DX-Forth program (actually, when you count in the SIO/2 driver it's 13 screens) providing a dumb simple "remote shell" which is accessible via Telnet.
I'm not sure if this will ever lead anywhere, but it's been a nice exercise and it shows that despite other claims, you actually can write more complex appications with Forth.
The demo code for the "bbs" and the SIO/2 driver for RC2014 can be found here:
something's cooking ... 
*whistling*
@quazarsamcoupe Just had to change the I/O port addresses to get my #TMS driver I've written in #DXForth to work with the Maccasoft TMS emulation firmware ... yay!
It's hot 
and I don't feel like doing anything useful. Yet, there's this little #breadboard #thermometer I plugged together about two years ago and I still have the #DXForth #code and my #i2c #drivers for it - so here's a photo of my #rc2014 thermometer ...
have a nice and cool weekend, y'all! 
DX-Forth 4.56 (released: May 10th, 2024)
I wonder how could I miss this one so just in case you missed it too:
There is a new release of DX-Forth out for DOS and CP/M - version 4.56 (released: May 10th, 2024)
CP/M Version:
https://drive.google.com/file/d/1qSob--doYwcUGTAcSwT8k9JQzFcX4fUo/view?usp=drive_link
DOS Version:
https://drive.google.com/file/d/1eTbc1ZG5IWfYjinls6zYnY70BbYlPF-M/view?usp=drive_link
#CPM
#DOS
#DXForth
#Forth
#RetroProgramming
#New
#Version
#Coding
