TheBF

Reminds me of the old American vaudeville joke: Patient: "Doctor, it hurts when I do this." Doctor: "Then don't do that!"

Well... I think I read that here somewhere, where a person did that for fast writes to the ports. Now I have to try it and see if it works.

There should be a prize for that that post. (I think I have heard that term on comp.lang.lisp)

I got this website via Reddit /Forth that gives a very comprehensive history of Forth. I looks like the writer has recently discovered Forth (created Feb 2023) and wrote up what he has found over the course of the year. It's a good reference site for history and other web links. Forth: The programming language that writes itself: The Web Page (ratfactor.com)

Yes my understanding from the code is that is measures how long it takes to go from mark to space. I only tested with the enter key actually. There might be a key that beats it. ?? You are too clever. I was wondering if I could do more with the framing error but it starts to get bigger. It's 130 bytes now and I think that's probably enough. When vi99 boots on the version I am working on, it writes to the VDP screen and says: VI99 TTY EDITOR RS232/1 8,n,1 RTS/CTS handshake Press enter on your terminal to set the baud rate

That's a healthy list. :-) (and one evil ELSE removed) I seems like there are some operational changes like the loop stuff that mean the new version works a little different than the previous version so a new major number is probably a good idea. I always wondered why FBFORTH asks me if I want white on blue screen colours rather than just doing it. ?

I finally figured out how to get this code working that I found in an old TI book from 1981, called Software Development. "2nd Edition" The way the thing works is: Reset the UART Set the protocol control register to a predefined value (Camel99 is 8,n,1) Loops until the UART input line goes low, the "mark" condition, meaning a key was pressed. Enters a counter loop waiting for the input line to go high. The value of the counter is compared to a *table entry, that also has the correct baud rate divisor for each timed value. Set the baud rate register to the value in the table. Read a key and throw it away. I had to change the table values to match the timings of a TI-99 with registers in scratchpad but the program running in expansion RAM. They were about 2X smaller than the values in the TI book because our machine is slower. The other thing that tripped me up two years ago was the need to reset the input buffer bit. This is not in the original code but was needed for Forth running over the serial port. I suspect because I hit a key to start autobaud but then the autobaud program resets the UART and the key is not read. I added one more table entry so you can use 38400 bps. The video shows the operation. Code is in the spoiler. https://youtu.be/923vD4ElP9Q

funny you should mention... I just got code working that does AUTOBAUD selection from 110...38400 bps. Of course the "mark/space" timings are for TI-99 expansion RAM so they would need to be changed for your machine but it works!. I will be publishing the code over on Camel99 thread.

Very fun. Heathkit was the best! I am going to try to make an autobaud detector. I have some example code here from TI so give me a while and maybe it will just need a few carriage returns off the top to detect the baud rate. If that fails, I should be able to make a config file that loads off the top with a the configuration text. I will try to do that first and get you that version. There are a couple of other oversights in the man page I need to fix up too.

Sorry to hear about that. I have read that a lot of us are Vitamin D deficient these days and that Vitamin D is more important for immune systems than we realized. (I wonder why I would be low, when I live in the basement with my computers) Anyway I started taking 2000iU back when the pandemic got rolling. I noticed that my Asthma is less of a problem, so there's that. I think in normal doses it's like chicken soup. It ain't gonna hurt and it might help. Get well soon.

Congratulations Jesper. Sounds like you had some fun with this one and gathered some insights into not just Forth but this old hardware as well. How many instructions in an interrupt. Good question. Grabbing a napkin and turning it over ... We would probably never want the interrupt to consume more that 10% of the CPU so let's just assume that as a requirement. That means in a North American machine we have 1/60 of a second, or 16.666mS / 10 = 1.666 mS to work with or 1666uS This is what kills the 9900. Cycles per instruction is ghastly. I just took a random freeze of instructions running in ROM with the E/A Cartridge plugged in. OMG look at the 2nd last instruction. 0496 045B b *R11 (12) 0070 0300 limi >0002 (16) 0074 0300 limi >0000 (16) 0078 D25D movb *R13,R9 (41) 007A 1105 jlt >0086 (8) 007C D109 movb R9,R4 (14) 007E 09C4 srl R4,12 (36) 0080 C164 mov @>0c36(R4),R5 (22) 0084 0455 b *R5 (12) 011A D120 movb @>837c,R4 (22) 011E 0A24 sla R4,2 (16) 0120 11FA jlt >0116 (8) 0122 D81D movb *R13,@>83f3 (49) 0126 0249 andi R9,>1fff (14) The average clock time for these instructions is 20.4 per instructions. Total clocks are 284 so this would run in 284 x .333uS = 95uS But this is on the 16 bit buss, so full processor speed. If our code is running in the Expansion Ram we need to add about ~25% , so this would take 119uS running on the 8 bit buss. And the average would go up to 25uS per instruction. So 1666 uS / 25 uS ~= 67 instructions. On a European machine we would have a bit more at 50Hz video rate. 2000uS / 25uS = 80 instructions for 10% of the CPU time. At least that's what my napkin says.

Sorry the delay. The wife had other plans for me. Custom version is called VI99TTYV where V is for Vorticon. The source code was edited with VI99 TTY and recompiled from floppy disk on real iron. I also remove the debug display on the VDP screen to help speed this version up a bit. vi99ttyv vi99ttyw vi99ttyx VIMANPAGE

The vimanpage file is the cheat sheet. VI99TTY/src/VIMANPAGE.TXT at main · bfox9900/VI99TTY · GitHub I can make you a custom version. It will take a few minutes because I build it with floppy disks.

So did you do something like ANDI *SP,>FFFE

The silence is killing me. Has anybody started this thing? Is it useable for normal humans? (versus a Forth nerd)

Ya I think the days of "A computer will never do that" are pretty much over.

Just to exhaust the topic, I found this fancier version of synonym that deals with proper action for Immediate synonyms. I had never consider this before. Of course a commercial system maker would have to cover all the bases. \ From "reference implementation". Used by VFX Forth : SYNONYM \ "newname" "oldname" -- \ Create a new definition which redirects to an existing one. CREATE IMMEDIATE HIDE ' , REVEAL DOES> @ STATE @ 0= OVER IMMEDIATE? OR IF EXECUTE ELSE COMPILE, THEN ;

Don't feel bad. With Alpha Go chess nobody else in the world understands what it's doing either.

In ANS Forth synonyms are based on the CFA. Would that be a better way? \ synonym for NON-CODE words BJF Sept 27, 2018 : SYNONYM ( <newname> <oldword> ) CREATE ' , DOES> @ EXECUTE ;

Since you understand the dictionary structure and you are traversing using 2- @ then I can't see how that would be a problem.

Ah. Yes it only worked for FCOMP. Shame. I am always surprised by some of what we find in the old 99. But I guess when the gun is to your head you make it work and make it better later. Those corporate execs are brutal. (Used to be one for a time )

OK. What I was wondering about was would it be possible to point both FAC and ARG to positions on the DATA stack by setting the registers in the ROM code, thereby reducing data movement for Floating point routines to just one move, onto the DATA stack. I am thinking about something like SP@(x) and SP@(y) being fed into the two appropriate registers used by the ROM code. I got the sense that since you were jumping into the code downstream so-to-speak, you had direct access to where FAC ARG could be stored. (But I know nothing about these ROM routines.) Just a crazy thought. But all that copying from the stack to memory and back seems a waste when you have a stack. (Are FAC and ARG in CPU RAM? Maybe I am talking trash, if they are in VDP RAM.)

I also have a text editor. There is a 40 column version for standard VDP chip systems. It uses SAMS to hold multiple files. I would be interested in hearing about projects people wish they had for SAMS cards. I am always interested in seeing what I can do with my little system.

Looks like you can book about 15% better on the transcendentals. That's damned good. How did you end up handling the FAC ARG thing. Is ARG taken from the data stack?

Start up with a terminal emulator at 19200 8,n,1 At the command prompt type: BA=1200 OPEN-TTY The plug into your EP-44 and see what happens. Thank's for giving it a spin.