drogon wrote:
I needed to get the image to 24K. I simply used 'dd' to truncate it to 24K. This didn't initially go well, so had to remove the .advance directives in the platform file. (so the suggestion here is to just generate the 24K image with notes to allow others to bolt-on their own OS bits)
The idea behind generating a 32K image was to try to make it easier for folks just starting out so they can just program a 32K ROM. Adding a method to generate a 24K image is a good idea, and I'll look into that.
drogon wrote:
(Also; Linux. Good thing that's what I use... I've no idea how MS Pc/Mac people would cope with a Makefile and Python)
All of the Tali developers are definitely using Linux, and it shows, but Tali will compile on windows either by using cygwin (to get python and make) or by installing python and gnu make separately. Macs come with python and make already installed these days. Python is not a language I enjoy using, but it's what the project was using when I stumbled on it.
drogon wrote:
End of line output is NL only, so had to make my putchar routine add a CR. (so again, notes, or an option in the system itself to do the CR+LF thing)
That's a good one I hadn't thought of. I have my terminal set up for only LFs, but I agree that you should be able to set that up or that it should be documented on exactly where to adjust it. The putchar routine is probably the best place.
drogon wrote:
I had to change buffer0 start to higher in RAM for my system ($0E00) I was glad that option was there - and seems to work.
I'm glad that worked out for you. Tali is quite tolerant of what ends up where in memory as long as it knows.
drogon wrote:
What I would like is some hints to read the input line before forth sees it - the way I do that in Applesoft and ehBasic is to peek at the first character of the input buffer and see if it's a star (*) and if-so, then call my OS, so typing *cat would work, slightly more forth compliant might be star ." cat" but harder to type... The main reason for this is that I then have a means to read text input from a file via the *exec command, so it would make an easy way to get files into the running forth without writing additional words into it to call the filing system.
If you want to peek in the input as it is read, you can check out ACCEPT (search for xt_accept:) in native_words.asm and the spot where the entire line has been read in is the _done: label. This is just before it has been placed in the history. The number of characters is located at "0,x" and the address where the string starts is in "2,x" and "3,x", but it is also more conveniently in the two-byte variable "tmp1" in ZP.
If you want just after it has been saved in the history instead, then the z_accept: label (just before the rts) is the spot and the values are in the same locations.
The "recommended" way would be to create a new forth word to accept any string and hand it to your OS routine. If you know the address of a routine, you can run it directly in Tali Forth 2 by using the execute command like so:
Code:
hex
F123 execute
decimal
The hex and decimal switch the number encoding for input and output in Forth. The F123 is the address in hex, and the execute word will run it. To make this a word, like "os" (the word * is already taken, and while you can redefine it, you might miss multiplication later) you might say:
Code:
\ This is a comment.
hex \ Switch to hex mode to make addresses easier to enter
: os \ Make a new word named "os"
F123 execute \ Just run the assembly routine at a known address
; \ Finish with the word. It is now available for use.
decimal \ Switch back to decimal (unless you really like hex)
\ Run the cat command.
s" cat" os
Your routine just needs to know that the character count is at "0,x" and the address is in "2,x" and "3,x" and it should probably save and restore the X and Y registers. It should remove the string address and the number of characters in the string from the data stack by running inx 4 times (or adding 4 to x). I'm assuming you'll need to shuffle things around to the locations your OS is expecting to process the line. If you get this working, you can add the forth code to "forth_code/user_words.fs" and it will be run at startup of Tali Forth so that the "os" word is available for any Forth session.
The "better" way would be to just write your "os" routine using the built-in assembler, but if you're just starting to play with Forth, that might not be a good place to start. Forth assemblers are often considered "extra weird" if you haven't gotten used to Forth yet.
drogon wrote:
As my Ruby system is sort-of BBC Micro-like, the binary I've made would probably work on a BBC Micro 6502 2nd processor but I've not had a chance to try it. To make it properly work the start of usable RAM (OSHWM or Page in Acorn terms) ought to be obtained from the OS rather than hard-coding in $E00 but it's not that big a deal here.
Tali Forth 2 requires a 65C02 processor. It won't run on an older 6502.
drogon wrote:
I just got some code from another Forth enthusiast to try - failed at a lack of a 'ms' word for some timing - which I understand is going to be very platform dependant anyway, however I may look at the docs to see how to implement it but when I tried to add in the star command stuff it all broke very badly, so I suspect I'm stepping on stack or something else that it didn't like and not being a Forth programmer, some of the acronyms in the source mean nothing to me.
A quick and dirty ms word (assuming it takes how many milliseconds on the stack) might look like:
Code:
: ms 0 do? ( nothing ) loop ;
ms isn't a standard word, but it should be easy to implement. The code above loops the correct number of times, but doesn't actually do the delay as that would be hardware specific, as you correctly stated. If you want to post the code you are interested in, I can probably help you get it running. If you tell me your CPU clock speed, I can help you get the timing close as well.
drogon wrote:
A "nice to have" would be the option to call an operating system routine to get a line of text - my OS supports command-line editing and history and I've changed applesoft and ehBasic to use it (bbc basic and other Acorn languages use it by default) so there is a common-user experience, however I appreciate that the number of users using my system right now is one...
xt_accept in native_words.asm is the code to replace. If you want to leave the existing code there for reference, you can replace it with your own routine, which might have the structure:
Code:
; The "XT" is the execution token, or address of where the function starts.
xt_myaccept:
jsr underflow_2 ; Check for 2 arguments (address numchars) on data stack
; Put your code here
z_myaccept: ; A label just before the final rts is needed.
rts
Your code will need to take a count (0-255) at "0,x" and the address of where to put the string at "2,x" and "3,x". When it's done, you need to remove one of the arguments on the data stack, which is kept using the X register ("inx" twice to remove one 16-bit value) and then fill "0,x" with the number of characters read and "1,x" with zero. You can use any of the ZP temporary variables (eg. tmp1, tmp2, tmp3 (16-bits each)) that are used in the existing version of ACCEPT.
If your code can meet those demands, you should totally be able to replace the existing version of ACCEPT.
Then you can go into headers.asm and locate the header for the accept word.
Code:
; Change...
nt_accept:
.byte 6, UF+NN
.word nt_input_to_r, xt_accept, z_accept
.byte "accept"
; To your version...
nt_accept:
.byte 6, UF+NN
.word nt_input_to_r, xt_myaccept, z_myaccept
.byte "accept"
This will now use your version for all calls to accept. You can check out the "Internals" chapter in the manual for more detailed information.
One note about doing this is that it will break the ability to redirect the input (I/O is vectored in Tali2), but I don't believe that breaks anything in Tali itself - you'll just lose that ability. It's probably not a big loss if you just want to play around with Forth.
drogon wrote:
However on the whole, not much harder for me to port than ehBasic.
I'm glad to hear that. That was the goal of the project. Thank you for taking the time to outline the sticky points in the porting path. I think you've shown some places where porting can be made easier for new folks.
-SamCoVT