Porting BASIC Code from Classic 8-Bitters to FreeBASIC?

General discussion for topics related to the FreeBASIC project or its community.
Post Reply
load81
Posts: 6
Joined: Mar 22, 2019 23:21

Porting BASIC Code from Classic 8-Bitters to FreeBASIC?

Post by load81 »

Have very many of you ported code from classic 8-bitters such as the C64, Apple 2e, BBC Micro etc. to FreeBASIC? I'm thinking about porting some C64 games that appeared in some type-in magazines I have floating around. I'm not as old as that makes me sound. Ha Ha.

For the inline assembly stored in DATA statements — I hate those — I know I'll just have to figure it out by hand and rewrite an equivalent function. The open questions I have are:
  • What's the best way to handle 8×8 bitmap tiles? Obviously, it's not going to be "overwrite the system font."
  • Is there anything like sprite functionality in FreeBASIC? I'm just getting my head wrapped around the documentation.
  • Other than needing to rewrite PEEKs and POKEs into platform agnostic functions what other issues am I likely to run into?
  • Oh, yeah. Timing. Lots of these games assume a ~1MHz clock in their control loops. What's the best way to keep code timing sane when porting to FreeBASIC?
I know I have to live without sound support for now. Bummer. But as near as I can tell from other threads here that problem is being worked.
grindstone
Posts: 862
Joined: May 05, 2015 5:35
Location: Germany

Re: Porting BASIC Code from Classic 8-Bitters to FreeBASIC?

Post by grindstone »

load81 wrote:What's the best way to handle 8×8 bitmap tiles? Obviously, it's not going to be "overwrite the system font."
With IMAGECREATE you can create tiles of any desired size.
Is there anything like sprite functionality in FreeBASIC?
No. You have to deal with this stuff yourself. But there are some very similar solutions already coded by other users.
Other than needing to rewrite PEEKs and POKEs into platform agnostic functions what other issues am I likely to run into?
No universal answer to that question. It depends on what you intend to do.
Oh, yeah. Timing. Lots of these games assume a ~1MHz clock in their control loops. What's the best way to keep code timing sane when porting to FreeBASIC?
Empty FOR...NEXT - loops for timing don't work on FB, because they are optimized away by the compiler. But there's a much better way to substitute it:

Code: Select all

Dim As Double t
...
t = Timer
Do While t + .1 < Timer
Loop
will achieve a delay of 100 ms - independent from the system speed.
badidea
Posts: 2591
Joined: May 24, 2007 22:10
Location: The Netherlands

Re: Porting BASIC Code from Classic 8-Bitters to FreeBASIC?

Post by badidea »

grindstone wrote: Empty FOR...NEXT - loops for timing don't work on FB, because they are optimized away by the compiler. But there's a much better way to substitute it:

Code: Select all

Dim As Double t
...
t = Timer
Do While t + .1 < Timer
Loop
will achieve a delay of 100 ms - independent from the system speed.
Exact timing requires indeed the timer, but:
This code will make your CPU hot, and don't leave time for the CPU do other things.
Use a "sleep 1" (or similar, different OS or versions of a OS have different timing of processes) in the main loop somewhere .
Timing is very different then 20 years ago (OS and CPU's are different).
A simple methode is to use dodicats 'fps regulate' (somewhere on this forum).
badidea
Posts: 2591
Joined: May 24, 2007 22:10
Location: The Netherlands

Re: Porting BASIC Code from Classic 8-Bitters to FreeBASIC?

Post by badidea »

load81 wrote:I know I have to live without sound support for now. Bummer. But as near as I can tell from other threads here that problem is being worked.
You can use the fbsound library, but first get yourself familiar with freeBASIC.
angros47
Posts: 2326
Joined: Jun 21, 2005 19:04

Re: Porting BASIC Code from Classic 8-Bitters to FreeBASIC?

Post by angros47 »

load81 wrote:Have very many of you ported code from classic 8-bitters such as the C64, Apple 2e, BBC Micro etc. to FreeBASIC? I'm thinking about porting some C64 games that appeared in some type-in magazines I have floating around. I'm not as old as that makes me sound. Ha Ha.
Many of these programs had some parts written in BASIC, and others written in 6502 Assembly (or not even assembly... raw machine language, coded as a sequence of numbers). Unless you know wxactly what they are supposed to do, porting them is not easy

What's the best way to handle 8×8 bitmap tiles? Obviously, it's not going to be "overwrite the system font."
There are many examples, like this one: viewtopic.php?t=15902
Is there anything like sprite functionality in FreeBASIC? I'm just getting my head wrapped around the documentation.
The simplest way is to use the command PUT. It doesn't preserve the background, differently from a real sprite, but if you use a scrolling background you will have to redraw it at every frame anyway.

Otherwise, you can save and restore the background with GET and PUT:

Code: Select all

	screenRes 800, 600, 32
	' Draw a simple background.
	for i as integer = 0 to 800 step 20
	 line (0,i) - (800, i)
	 line (i,0) - (i, 600)
	next i
	' Set up an image and draw something in it.
	dim img as any ptr = imageCreate (32, 32, rgba(255, 0, 255,0))
	dim back as any ptr = imageCreate (32, 32, 32)
	circle img, (16, 16), 15, rgb (255, 255,   0),     ,     , 1, f
	circle img, (10, 10),  3, rgb (  0,   0,   0),     ,     , 2, f
	circle img, (23, 10),  3, rgb (  0,   0,   0),     ,     , 2, f
	circle img, (16, 18), 10, rgb (  0,   0,   0), 3.14, 6.28
	dim as integer x, y, ox, oy
	ox =- 100: oy =- 100
	for x = 0 to 768
	 y = 300 + sin(x/57) * 200
	 ' Restore the background.
	 put (ox, oy), back, pset
	 ' Save the background that will be overwritten by the sprite.
	 get (x, y) – (x+32, y+32), back
	 ox = x: oy = y
	 ' Draw the sprite.
	 put (x,y), img, alpha
		 
	 sleep 2
	next x
	' Wait for a keypress.
	sleep
Other than needing to rewrite PEEKs and POKEs into platform agnostic functions what other issues am I likely to run into?
Different resolution, different controls, different management of the screen (on a Commodore 64 you could embed control character to clear the screen, change colors, and so on in a simple string, this doesn't exist in FreeBasic)
Oh, yeah. Timing. Lots of these games assume a ~1MHz clock in their control loops. What's the best way to keep code timing sane when porting to FreeBASIC?
Use the TIMER variable, or the command SLEEP, as other people have already told. Never assume that a FOR cycle will take a constant amount of time, not even on the same computer (execution speed might vary, in a multitasking environment, since processor could slow down a task to dedicate more time to another one)
I know I have to live without sound support for now. Bummer. But as near as I can tell from other threads here that problem is being worked.
Personally I developed an experimental library that should help you generate sounds in FreeBasic. You can find it here : https://sourceforge.net/projects/freeba ... ary/files/

It can, among other things, be used to emulate the SID chip, and many others.
Post Reply