How fast is Turbo Forth compared to Assembler?

[courtesi96]

I see a demo of Super Mario Bros floating around; could this have been done in 100% Turbo Forth?

 

If not, how does someone decide whether or not a port may or may not work under TF?

[+chue]

 

How fast is Turbo Forth compared to Assembler?

 

There's a thread here that compares the various languages doing a simple benchmark:

 

http://atariage.com/forums/topic/248187-benchmarking-languages/?p=3784382

[Asmusr]

If Turbo Forth is 5-6 times slower than assembly as the benchmark shows I would say no: you couldn't make the Super Mario Bros demo in TF. Unlike many of my demos and games that are spending most of their time in tight loops pushing data to the VDP, the SMB demo is depending on the F18A for scrolling and is using most of its time on game logic. So even adding some assembly routines to TF to do the heavy lifting wouldn't help much in this case. I'm sure lots of other arcade games are possible in TF with or without the F18A.

 

Edit: I should mention that I was running out of CPU power in the SMB demo, which is one of the reasons I stopped developing it.

[+TheBF]

Well...

Turbo Forth has its own Assembler. Which is easier to use than the TI assembler. So real Forth programmers write in Forth then optimize the right loops with Forth Asm routines.

If you check the Tursi benchmarks postings you will see that I got the benchmark down to 6.5 seconds in Forth versus 5 seconds in the optimized Assembler version. And if I needed 5 seconds I would just write the outer loop in Forth Assembler too.

 

Remember when Tursi re-wrote the code using BLWP system calls the way you would start a project it took 17 seconds versus 48 seconds in in-optimized turbo Forth.

That is less than a 3 times difference in an apples to apples type comparison.

 

There are industrial examples at Forth Inc where they rewrote customers products that were in Assembler or C where the final Forth version was faster because they could test algorithms interactively and find better methods to solve the problem.

 

Algorithms normally beat language.

BF

Edited June 22, 2017 by TheBF

[+TheBF]

FYI by "easier to use" I mean it is interactive in a way that is hard to imagine for Assembly language programmers.

 

You can write a simple code routine at the console like in BASIC and test it immediately.

Do this a few times and join them all together as a high level Forth routine and test that interactively.

 

It's pretty fun.

 

B

[apersson850]

That's one of the best things with Forth.

[Willsy]

My experience and intuition is that the majority of games that were written in assembler in the 80s could be written in TurboForth. For example, Buck Rogers should be straightforward in TF. Same for TI invaders. Alpiner? No problem. Parsec? No. Couldn't do the screen scrolling.

 

Vorticon did a port of Jetpac (Sinclair ZX Spectrum, 1983) using TurboForth. IIRC I'd say more than 98% of it was written using straight Forth code. I think I helped with some machine code to do sprite to background checking and maybe some sound stuff.

 

Even the RLE encoded bitmap title screen is decompressed using straight-ahead Forth code.

 

A cool thing was we were able to get it into a standalone cartridge. It's Jetpac in a cartridge with TurboForth "underneath".

 

Edited June 22, 2017 by Willsy

[Willsy]

Here's one I did 5 years ago. It was *seriously* easy to write. Done in an afternoon.

 

[Airshack]

Here's one I did 5 years ago. It was *seriously* easy to write. Done in an afternoon.

 

 

 

This is so cool! You did this in an afternoon and it was "easy" to write?

 

That's some skill you have cultivated my friend.

[courtesi96]

Do you think TurboForth could handle something like this?

 

This is a TRS-80 CoCo game:

 

[Willsy]

I watched the whole video and I'm not seeing much that is particularly challenging. Things like scrolling the screen already exist in TF.

 

I'm seeing what looks like an 8x8 man, 8x16 ghosts/monsters, minimal animation (can be done by redefining colours or characters - very fast in TF).

 

The only programing "problem" you would have to solve (and this is nothing to do with Forth) is the map is very large, with quite a lot of rooms. So you'll need some sort of tokenisation system in order to represent each room as some sort of structure.

 

There's also the AI for moving the monsters intelligently. Again, not a problem that is specific to Forth. You'd have to solve it in any language. My approach in Forth would be to use DOES> and have a common set of routines for all monsters. Kind of like a class with multiple instances and common methods.

[courtesi96]

I forgot to ask - do you see anything in that game requiring a F18A?

Edited June 23, 2017 by courtesi96

[+adamantyr]

I'm more than familiar with that game, my brother had it on his CoCo.

 

The original CoCo used the 256x192 high-res mode with 4 colors achieved through artifacting. So it translates fairly well to the TI with one exception; the graphics are not perfect squares. If you notice, the scrolling window is 12x15 in size. That means the graphics are actually 12 pixels high, 16 pixels wide. You would either just need a smaller window on the TI and do 16x16 size graphics, or you'd need to use bitmap mode and do some clever tricks to split things.

 

My own feeling is, don't try and force something into a graphics mode that doesn't fit well, I'd go with 16x16 size to keep the scale looking good.

[+Vorticon]

TF is super easy to work with, especially when combined with the Classic99 emulator. Write the code in any modern editor like notepad++, then copy and paste in Classic99 then execute. No need to mess with paged Forth editors.

If I could write Jet Pac in TF, and I am truly an amateur hobbyist programmer at best, then imagine what a professional programmer could come up with!

You have direct access to all the TI features without even needing direct assembly coding in most situations, like the bitmap screen or the IO ports for example.

[courtesi96]

I watched the whole video and I'm not seeing much that is particularly challenging. Things like scrolling the screen already exist in TF.

 

I'm seeing what looks like an 8x8 man, 8x16 ghosts/monsters, minimal animation (can be done by redefining colours or characters - very fast in TF).

 

The only programing "problem" you would have to solve (and this is nothing to do with Forth) is the map is very large, with quite a lot of rooms. So you'll need some sort of tokenisation system in order to represent each room as some sort of structure.

 

There's also the AI for moving the monsters intelligently. Again, not a problem that is specific to Forth. You'd have to solve it in any language. My approach in Forth would be to use DOES> and have a common set of routines for all monsters. Kind of like a class with multiple instances and common methods.

 

 

I think as a first project I'm going to try and convert this over to TF. First obviously I need to learn TF which I am currently doing. But also, I'm going to put this game through a disassembler to get the 6809 code and comment it up a bit to figure out how it crams all those screens into 32k. Probably too aggressive to finish this year but may be ready to show off in 2018.

[Willsy]

Rather than jump straight into a big project like this I would recommend smaller steps. Don't try to run before you can walk. It takes time to get used to Forth and if you're not careful you can just end up with a mess!

 

Get a feel for the language and the system first. It's all experience that you will be able to capitalise on later.

 

And of course if you have any questions don't hesitate to ask. :-)