batariBasic for Lynx?

[+Philsan]

Thanks to batariBasic, many people can program games for Atari 2600 console.

Some games have commercial quality but IMHO the important thing is that everyone can enjoy programming his beloved machine.

 

I would love a Basic for Lynx too.

[42bs]

2 hours ago, Philsan said:

 

Thanks to batariBasic, many people can program games for Atari 2600 console.

Some games have commercial quality but IMHO the important thing is that everyone can enjoy programming his beloved machine.

 

I would love a Basic for Lynx too.

 

So take the chance and port it!

[+Philsan]

Atari 7800 console has a BASIC too, 7800basic.

 

Here's an example of what can be achieved with modern compiled BASICs:

 

[Lynxman]

On 9/24/2019 at 11:25 PM, 42bs said:

So take the chance and port it!

ACK

[Turbo Laser Lynx]

It would be interesting for sure to se what people would/could come up with using Basic. One thing I wonder about though, is if Basic is any easier than using C in a simple manner? Since there's good CC65 support for the Lynx and a wonderful template, pretty perfect for beginners to start experimenting with. I feel that using C like that is at least much easier than the old basics I've tried (Basic 2 on the C64 and Basic 7 on the C128). I haven't tried any modern Basic variants, so it might be those would be easier to use. Basic v.7 was quite nice at least.

Edited October 2, 2019 by Turbo Laser Lynx

[+Stephen Moss]

24 minutes ago, Turbo Laser Lynx said:

It would be interesting for sure to see what people would/could come up with using Basic. One thing I wonder about though, is if Basic is any easier than using C in a simple manner?

I don't think any sane person would want to program in machine code and the next best language for ultimate control and code efficient is Assembler which while more difficult than C or BASIC is still written in relatively logical and readable English.

Of C and BASIC which is best generally comes down to personal preference, and as to which produces the most efficient code is down to the efficiency of the compiler rather than the programming language.

 

Personally, I find BASIC easier then C, although they share many of the same commands such as If, Then, Else, Do, Until, While , Wend etc. I just find that with C...

a) its syntax a little more difficult to read as it uses less of a full sentence (as it were) compared to BASIC,

b) You spend half you life putting in curly brackets and semi colons at the end of each line of code (who though that was a good idea!) unlike BASIC and

c) In my experience when an error is reported in BASIC it is usually in the reported line of code where as in C it is often due to an easily omitted semi colon or curly bracket that is locate some distance from the line of code where the error is reported which you then spend ages looking for it.  

[Nop90]

I think that the key success factor of bBasic over ASM on the 2600 is that it provides basic coding blocks to setup a game without the need for the coder to know the HW so deeply.

 

I's a sort of a RAD: so it's not the BASIC language to makes the big difference (it helps a little since has a fster learning curve and the coder had not to type a lot brackets that are not present on some of the non US PC keyboards ?) and the same thing could be done with C.

 

Is it worth to have such a tool with the actual small number of active coders and retrofans of the Lynx? Would it attract more coders to this platform?

 

Really can't answer.

 

[+Philsan]

In fact CBM Basic V2 is not very useful to manage graphics and sprites.
You have to use POKEs and PEEKs.

On the contrary, CBM Basic v7 is very nice but obviously slow.

Modern BASICs have commands to manage graphics and are very fast.
Therefore there are many good quality games for the humble VCS 2600.

Yes, Lynx user base is narrower than VCS.
But 7800 user base is narrower too but it has a Basic.

Considered how many multicarts have been sold recently, I think Lynx user base is not small.

[+karri]

True. The new screens and multicarts brought a completely new way of distributing high quality content to the Lynx at am affordable price. I mean 11 new amazing games only this year. Downloadable for free. Without ads. Without pay for play stuff that plagues most new games that you get for "free".

 

But I see the point in bringing in a good Basic environment for Lynx programmers. Without a need to do peek/poke for ordinary graphics.

 

The interactive nature of Basic requires some kind of keyboard. Perhaps a ComLynx keyboard combined with Basic in ROM and lots of eeprom for storing the data would be usable?

 

I assume that Basic users want line numbers and not structural Basic.

10 PRINT HI

20 GOTO 10

[LordKraken]

And don't forget that the best games will get released on a R-E-A-L cartridge, with paper, plastic and PCB. All non ecological sure but still... this childhood pleasure to open a box

[+karri]

45 minutes ago, LordKraken said:

And don't forget that the best games will get released on a R-E-A-L cartridge, with paper, plastic and PCB. All non ecological sure but still... this childhood pleasure to open a box

Don't worry. I just got a confirmation that my CARDBOARD boxes arrive on Friday. My CARTS are already assembled. My LABELS are already printed.

 

But the

...INSTRUCTION sheet is still to be designed
...FINAL BOSS is still pathetic

...SECONDARY storyline lacks levels
...FEELGOOD level is not working
...COFFE SHOP BOSSANOVA for the secondary storyline still sounds awful

...TIME is getting short. My flight leaves in two weeks. Oh "creativity and good taste" where are you when I need you?

 

The worst case is that I get the last stuff coded at night in some shady Portland hotel while suffering from time lag on the opening morning of PRGE.

[Turbo Laser Lynx]

2 hours ago, Stephen Moss said:

You spend half you life putting in curly brackets and semi colons at the end of each line of code (who though that was a good idea!) unlike BASIC and

Haha, I get your point. Personally I find programs without these wery hard to read. But obviously it plays a big part what language you've gotten used to in the first place too.

 

1 hour ago, Philsan said:

In fact CBM Basic V2 is not very useful to manage graphics and sprites.
You have to use POKEs and PEEKs.

I've seen many people argue that it was a good thing, because it forced them to get into assembler. Perhaps you guys have heard about 8-bit guys dream computer, the X16? It is supposed to come with a slight variant of CBM Basic V2 because of this reason. I see the point but I guess this discussion is more about having a tool/language to create games in the easiest way possible and not to learn the machine in depth though.

 

1 hour ago, Philsan said:

On the contrary, CBM Basic v7 is very nice but obviously slow.

Yeah, it's really easy to get things going since you have commands for graphics, music and even a built in sprite editor etc. But very slow as you say. Also it surprised me a bit that it was NOT easy to learn / set up user defined characters as a background the first time around (the way 99% of c64 game graphics are made anyway), had to do quite a lot of poking. Not being able to set up a base for a "real" game like this was a major disapointment as a kid so I just had to learn it now 30+ years later, and I'm glad I'm did, because I learned a lot of new stuff about how old  computers work. As you can see it takes half a minute to loop through color ram and Basic is too slow to stack two sprites (a multicolor sprite for color and a hires sprite for outlines), so that's why the main character is "ghosting" when moving
 

 

1 hour ago, karri said:

True. The new screens and multicarts brought a completely new way of distributing high quality content to the Lynx at am affordable price. I mean 11 new amazing games only this year. Downloadable for free. Without ads. Without pay for play stuff that plagues most new games that you get for "free".

 

But I see the point in bringing in a good Basic environment for Lynx programmers. Without a need to do peek/poke for ordinary graphics.

 

The interactive nature of Basic requires some kind of keyboard. Perhaps a ComLynx keyboard combined with Basic in ROM and lots of eeprom for storing the data would be usable? 

 

It's so much fun living in a parallel universe and follow the retro computing scene! 

Hahaa! I didn't even come to think of the idea of doing it straight on a Lynx. Really fun idea! The small screen would be/become a problem though. I thought it was even quite hard reading Basic on my c128 last xmas (when I did my first "retro coding" outside of the Lynx) although it has double the screen resolution of a Lynx.

 

Quote

Oh "creativity and good taste" where are you when I need you?

Hahaha! It's very hard to summon when you'd need it the most. Perhaps cut down on the scope a little? It's still one of the bigger Lynx homebrew games ever made so far, come to think of it.

 

Edited October 2, 2019 by Turbo Laser Lynx

[+Philsan]

 

 

 

True. The new screens and multicarts brought a completely new way of distributing high quality content to the Lynx at am affordable price. I mean 11 new amazing games only this year. Downloadable for free. Without ads. Without pay for play stuff that plagues most new games that you get for "free".

 

But I see the point in bringing in a good Basic environment for Lynx programmers. Without a need to do peek/poke for ordinary graphics.

 

The interactive nature of Basic requires some kind of keyboard. Perhaps a ComLynx keyboard combined with Basic in ROM and lots of eeprom for storing the data would be usable?

 

I assume that Basic users want line numbers and not structural Basic.

10 PRINT HI

20 GOTO 10

 

Nowadays development is mostly done on PC with IDEs.

You code and with a click after a couple of seconds the program runs on the emulator.

Not only consoles (without keyboard) but also retro computer development is done in that way.

 

Modern BASICs like 2600 batariBasic or 7800 basic don't have line numbers.

 

 

[VladR]

Philsan alerted me to this thread in my 2020 10-Liners thread (in the 8-bit section). I wasn't aware there was no BASIC for Lynx, that's crazy!!!

 

It made me realize that about 6 years ago I wrote a VRBasic translator (BASIC -> C) that then feeds into the jaguar's C compiler.

 

Since we have the cc65 on Lynx, 95% of work has already been done by me and there hopefully shouldn't be too many issues with the cc65/6502 idiosyncrasies (compared to jag's C compiler).

It does, however, use Microsoft syntax, so not sure how well that would be received.

 

Here's one of the samples to show the syntax:

' VRBasic Sample 06 - Screen Drawing
' Sep-2013

Module Globals
	Dim lvlData() As Byte
	Dim ImgWall As Sprite
End Module

	' Draws a specific screen from the loaded map
Sub DrawScreen (ScrCol As Byte, ScrRow As Byte)
	Dim xpos As Integer = 0
	Dim ypos As Integer = 0
	Dim idx As Integer
		' idxOffset is an offset to get to next row in the map. It should be 8* (ScreensPerMapRow-1), e.g. 8 * (2-1) = 8 in our case
	Dim idxOffset As Integer = 8

		' This is our global index into the map array
	idx = (ScrRow*(3*8)*2) + (ScrCol*8)
		' Render 3 Rows
	For row = 0 To 3
			' Render Row of 8 Sprites per column
		For col = 0 To 8
				' Check for 'X' (ASCII:88) and draw the sprite
			If (lvlData(idx)=88) Then ShowImage (ImgWall,xpos,ypos)
			Else ShowBlankImage (ImgWall,xpos,ypos)
			End If
				' Irrespective of the 'X' we move right in the increments of Sprite Width
			xpos = xpos + ImgWall.xl
			idx = idx + 1
		Next
			' Update the xpos,ypos for the next row of sprites
		xpos = 0
		ypos = ypos + ImgWall.yl
			' Move the index into map data at next row
		idx = idx + idxOffset
	Next
End Sub

Sub Main ()
	SetGraphicsMode ()

		' This is our level data in a text format. Each screen is 3 rows by 8 columns, whole level has 2 rows of screens, each row having also 2 screens
		' Base advantage of this format is that one can edit whole map in a Notepad
	LoadTextData (lvlData, "c:\jaguar\_Projects\_VRBasic\src\Samples\ArtAssets\level00.txt")
		' This is our Wall Sprite
	LoadImage (ImgWall,"c:\jaguar\_Projects\_VRBasic\src\Samples\ArtAssets\TileA2_16_Colors_Palette.gif",8)
		' Push the palette colors at index 1 (for example)
	CopyPalette (1,ImgWall)
		' Update the Image data
	OffsetImage (1,ImgWall)

		' Render all screens, one after another
	For ScrRow = 0 To 2
		For ScrCol = 0 To 2
			DrawScreen (ScrCol,ScrRow)
		Next
	Next

	Wait (5000)
End Sub

Of course, the execution speed depends on C compiler, in our case, it would be cc65.

But, from coder's standpoint -  it's a BASIC, not a C (though, as much as I tried to provide human-readable error messages for common syntax errors, you would still get the C-style compiler messages for the unforeseen scenarios)

 

I should probably create a separate thread for this, I'll go do that now.

[+karri]

This reminds me a lot of my front end to Google Blockly Visual Novel compiler. Google used xml objects as an intermediate form. These were parsed by a Python program to cc65 source and then compiled.

 

I would suggest to use cc65 because of the segment linker that does a good job in switching binary blobs in from the cart on demand. Especially on large project like On Duty you save a lot of time when you don't have to deal with the hairy details all the time.