Author Topic: Brandy BASIC V  (Read 18530 times)

Offline Mike Lobanovsky

  • ON-HOLD
  • BASIC Developer
  • Posts: 237
Re: Brandy BASIC V
« Reply #30 on: January 08, 2014, 11:00:45 AM »
2.1GHz Athlon might be already a little too slow for modern realities. I'll be upgrading to i5-3470 3.2GHz any time soon and I think that's gonna keep me in the mainstream for a couple more years.

... It has become a de facto standard to have a 2:1 ratio on resolutions higher than that - so 800 x 600 uses logical co ordinates of 1600 x 1200 for it's plotting commands ...
Hehe, so it does apply a scaling transform to reduce the canvas size by 2 before blitting the final image into the window. That's exactly what I've been talking about even if not so clear and concise as you do. :) It also explains why your saucer looks so neat while 1:1 plots rendered in other languages are so scattered and untidy.

Talking about SDL, after some public tonguelashing by John on another BASIC forum, I've found out that both ATi and nVidia have released some decent hardware-accelerated proprietary video drivers for Linux platforms lately so HW-assisted 3D rendering in OpenGL is now not a problem under both pure Linux and that Wine half-breed thing they use to run the wealth of MS Windows graphics software on (:P John).

I don't however know if that concerns 2D blitting or if SDL can communicate with the drivers to have its blitting hardware-accelerated. This and also some recent findings by John that SDL's flood-filling may GPF if the outlines go off-canvas (evidently, due to SDL clipper bugs or glitches) are keeping me off of SDL when I'm pondering over my plans to extend FBSL to Linux too. Anyway, if you say SDL has a multithreaded software blitter then it may help somewhat but not so much as compared to system-wide HW-assisted blitting under MS Windows.

Feel free to let me know any time when you need my help. You may also e-mail me at my address which is now in your PM box. :)
Mike
____________________________________________________________________
(3.6GHz Intel Core i5, 16GB RAM / nVidia GTX 1060Ti , 6GB VRAM / x64 Win7 Ult.)

Offline John

  • Forum Support / SB Dev
  • Posts: 2345
    • ScriptBasic Open Source Project
Re: Brandy BASIC V
« Reply #31 on: January 08, 2014, 11:21:40 AM »
Quote
Nice to meet someone who actually wants to help :-)

Thanks Mike for chipping in and giving David someone to work with on the Windows side of this. As I had mentioned in a previous post, my interests in BBV is stabilizing the Linux version and getting it running on Android. I created the Bitbucket project as my searches for BBV related resources kept turning up dead links. It doesn't seem the author has much interest moving the project forward.

It makes it difficult to merge your fixes with the BBV version as your version is obviously Windows centric with a Linux port as an after thought. I think we have a good mix of talent involved in the BBV projects and it should be a lot of fun.

« Last Edit: January 08, 2014, 11:24:05 AM by John »

Offline Mike Lobanovsky

  • ON-HOLD
  • BASIC Developer
  • Posts: 237
Re: Brandy BASIC V
« Reply #32 on: January 08, 2014, 11:55:03 AM »
John,

I think Napoleon isn't so far from Linux as it may seem. I'm reading David's docs now and I like his idea of using OpenGL under Linux. I even think the Windows engine should evolve in that direction too. If you want to know my opinion (the very inmost one), I'd prefer to see my FBSL-to-Linux extension to be based on that too. It would kill the headaches of SDL or any other home-brewed graphics library totally. It would help create truly multi-platform graphics API's unified and HW-accelerated on all existing platforms. That would leave only one problem to resolve which would be platform-independent window manager et voila, you have an incredibly fast GDI and GUI on any platform you want while program flow control and maths is naturally universal by definition.

MS Windows GDI graphics is very fast but OpenGL is much, much faster. At the same time, contemporary OpenGL drivers are top notch on any platform. No more comparative benchmarking, no more competition, no more distraction from the main task of adding useful features to the language proper for the benefit of its users.

Napoleon is a relatively small and straight-forward project which may be a nice place to test and polish up methods and strategies that might help others to carry on with their own projects on any platform.
Mike
____________________________________________________________________
(3.6GHz Intel Core i5, 16GB RAM / nVidia GTX 1060Ti , 6GB VRAM / x64 Win7 Ult.)

Offline John

  • Forum Support / SB Dev
  • Posts: 2345
    • ScriptBasic Open Source Project
Re: Brandy BASIC V
« Reply #33 on: January 08, 2014, 12:06:55 PM »
I'm sticking with SDL at the moment for portability reasons. If I want to run BBV on Android anytime soon with touch, orientation, ...  SDL is the only way for me to get there. I'm limited to a SDL/JNI interface on that platform.

@David: My biggest hangup at the moment getting BBV to run on Android is the printf / fprintf console I/O. Has your version been changed to redirect this to your graphics UI?

« Last Edit: January 08, 2014, 01:09:50 PM by John »

David Burnard

  • Guest
Re: Brandy BASIC V
« Reply #34 on: January 08, 2014, 01:11:18 PM »
With regard to David Daniels (the author of Brandy Basic) not wishing to move it on, he confirmed this to me by email when I contacted him regarding my windows port.

He agreed I could add my name to the signon and that the name prefix of Napoleon was acceptable to him for my version.

He did say he was also pleased that people were still interested in the program   :)


Offline John

  • Forum Support / SB Dev
  • Posts: 2345
    • ScriptBasic Open Source Project
Re: Brandy BASIC V
« Reply #35 on: January 08, 2014, 04:27:32 PM »
Thanks David for the RND() fix. The following line you added was needed.

Code: [Select]
push_int(TOINT( (randomfraction()*TOFLOAT(value))+1) );

Here is a new polygon.nap screen shot with your fix.



David Burnard

  • Guest
Re: Brandy BASIC V
« Reply #36 on: January 09, 2014, 04:51:04 AM »
To be fair, this RND() and the random number seeding are the only bugs I've found in David Daniels original code -> Which is  awesome, the speed of the underlying interpreter is a tribute to his abilities !!

I see my version of the graphbank demo is picking up some artifacts from whatever program you used for the video capture :-(

But yes the SDL version does not implement shadow screen modes, this provides two screen banks for the display, so one can be used for drawing and the other for display, then swap the blocks for classic old style double buffering!! the feature was added to the Acorn MOS on the BBC Master computer, before that on the BBC Micro model A & B this wasn't possible as it didn't have enough RAM. It has been carried forward into Arthur OS and RISC OS ever since.

Is it part of BBC Basic? not in the strictest sense! but very useful none the less.

Is it possible to direct SDL to render its graphics primitives off screen to a back buffer?

Richard Russell in BB4W ignored the Risc OS implementation and introduced his own *REFRESH command for controlling display of the off screen composition buffer -> both methods are perfectly valid and as Richard was part of the original team at Acorn he can change the language as he chooses, but I'm using the RISC OS programming reference as my specification !! Roger (now Sophie) Wilson's original branch of the language is what I grew up with! and is still current in RISC OS 5.

Also pattern fills were added to the MOS on the BBC Master -> patterntest.nap and carried forward from then on (with a new method to define the patterns introduced on the Acorn Archimedes). These are also implemented on my windows version. :-)

In addition Acorn produced a GFX Rom for the BBC B to add this and some other VDU code features which were built into the newer BBC Master.


« Last Edit: January 12, 2014, 03:27:20 AM by David Burnard »

David Burnard

  • Guest
Re: Brandy BASIC V
« Reply #37 on: January 09, 2014, 06:08:45 AM »
As regards console IO my windows version does not use printf or fprintf at all now!
ALL OUTPUT CHARACTERS now pass though the VDU stream function  emulate_VDU(); and true_emulate_VDU(); (this was not true of the original screen rendering codes) where they are rendered to the bitmap and/or are passed on to other channels (only other channel implemented at the moment is the serial port)


start

Win32Basic.exe -com:<Serial port number> (best done from within a windows shortcut)

*fx 2

and

*fx 3

then control serial port redirection as per RISC OS Programmers Reference Manual

I have an emulate_printf() function which can print strings as per printf() through the VDU function for debug purposes.



John,

I have already urged you not to reinvent the wheel, I believe my solution is actually quite elegant and just needs the appropriate keyboard read and bitblit write functions adding to run under linux. These functions are available in SDL.

David Burnard

  • Guest
Re: Brandy BASIC V
« Reply #38 on: January 09, 2014, 06:19:28 AM »
John
 
The Shadow screen modes were added on the BBC Master in 1986, The book cover you've shown was from a book published in 1981, you aren't going to find anything about shadow screen modes in there !!!

David Burnard

  • Guest
Re: Brandy BASIC V
« Reply #39 on: January 10, 2014, 04:20:48 AM »
Yes John

It's something I fixed in my version, see keyboard.c , the original used a sigint exception to detect the escape key (sort of works in the original DOS version), I detect it in the keyboard polling loop, you can carry my code over wholesale if you can't figure it out yourself.

I do not want to spend my time explaining every change I made to create Napoleon Brandy Basic and whilst I don't want to be rude,  I don't approve of you resurrecting the original code base as a new project. Have you attempted to contact David Daniels and/or Colin Tuckley with respect to taking over the maintenance of their code?

As the code is open source you are of course free to take this course of action,  but I will get very annoyed, under these circumstances, if you expect me to explain ALL of the changes I have made!!

PS. Possible stability issues with the Load, Run and Chain commands --> be careful how you proceed.

Offline Mike Lobanovsky

  • ON-HOLD
  • BASIC Developer
  • Posts: 237
Re: Brandy BASIC V
« Reply #40 on: January 10, 2014, 04:25:17 PM »
... if I can get it running but it will be a personal effort and more than likely I will not release it. (ML: italization is mine)

John,

Please reconsider your own words very carefully. Do you mean that if you have to exert your personal effort then you're not going to share your results in public? Then how can you expect someone else's effort to be shared with you unequivocally in return? And then how can you advocate open-sourcing at all if you don't seem to be prepared to share your own produce generously and unconditionally?

It seems like you have just scared away a nice guy and an eager and capable developer too. Yes, his project is MS Windows-"centered", as you put it, at this point. But so is Charles', Eros', and mine. Should we also go now? Do not look down on Windows so shortsightedly as I don't see very many Linux addicts here to share your company for a change.

And why didn't you ask me if I would want a dozen or so of my own messages to be gone without prior notice?

I did notice that the entire thread was gone from the forum. I think I wasn't the only one to notice it but we're already accustomed to such twists somehow. I think you had better leave it at that than revive the thread using such dubious phraseology.
Mike
____________________________________________________________________
(3.6GHz Intel Core i5, 16GB RAM / nVidia GTX 1060Ti , 6GB VRAM / x64 Win7 Ult.)

Offline Mike Lobanovsky

  • ON-HOLD
  • BASIC Developer
  • Posts: 237
Re: Brandy BASIC V
« Reply #41 on: January 10, 2014, 05:43:03 PM »
OK John, let's leave it at that. Perhaps things are not as bad as they might seem to you or me; time will show. :-\
Mike
____________________________________________________________________
(3.6GHz Intel Core i5, 16GB RAM / nVidia GTX 1060Ti , 6GB VRAM / x64 Win7 Ult.)

Offline Mike Lobanovsky

  • ON-HOLD
  • BASIC Developer
  • Posts: 237
Re: Brandy BASIC V
« Reply #42 on: January 10, 2014, 09:08:08 PM »
Thanks for restoring the thread, John!

It's already part of NBB's history and I guess there's nothing so bad in it as to have it buried so early. Time does fly and if all goes well, David will have his project polished soon enough to be ready to proceed to other platforms of his choice. Perhaps he feels he should have a perfectly working proto first before he moves on.

These are only my speculations, of course, but something's telling me he'll eventually calm down and will realize that steel gets only harder when tempered.

That's life. :)
Mike
____________________________________________________________________
(3.6GHz Intel Core i5, 16GB RAM / nVidia GTX 1060Ti , 6GB VRAM / x64 Win7 Ult.)

David Burnard

  • Guest
Re: Brandy BASIC V
« Reply #43 on: January 11, 2014, 06:58:27 AM »
John,

Please don't mess with these exception handlers unless you REALLY know what is behind them in your OS!

They are to handle system events (interrupts) , Sigint is the only one you need be concerned about!

Quote

#ifdef TARGET_DJGPP
    sigintkey = __djgpp_set_sigint_key(ESCKEY);
#endif
#ifdef TARGET_MINGW
    /* Launch a thread to poll the escape key to emulate asynchronous SIGINTs */
    if (sigintthread == 0)
      sigintthread = CreateThread(NULL, 0, (LPTHREAD_START_ROUTINE)&watch_escape, NULL, 0, NULL);
#endif




The code for the TARGET_DJGPP sets up an interrupt under DOS and links it with the Escape Key, this then diverts the interrupt to the exception handler routine! this means that the escape key is handled asynchronously to the basic interpreter, which was done to allow Escape to work even when in the middle of a System() call to the OS, used for *commands

Under a Linux console I believe the default key combination of Sigint is Ctrl C, hence the program breakout with this key combination !

The TARGET_MINGW code sets up a thread to monitor the Escape key using the polling function watch_escape(), this code should be applicable under linux but you may (or may not) have to rewrite the watch_escape() function !

Quote

#ifdef TARGET_DJGPP
    (void) __djgpp_set_sigint_key(sigintkey);
#endif
#ifdef TARGET_MINGW
    if (sigintthread != NULL) TerminateThread(sigintthread, 0);
#endif

This code removes the handlers before BASIC exits


The use of an asynchronous escape event causes a whole raft of possible problems which are not deterministic in nature, making debugging a nightmare, hence my decision to look for the Escape key in the keyboard polling loop, I then always know the calling point for the escape event and the behavior is deterministic. The down side is that you then need to implement emulation code for all the shell commands you would have called by the System() function but this command opens a console window (which is undesirable) anyway.   

PS The "shell" type *commands in BB4W are all emulated too !

David Burnard

  • Guest
Re: Brandy BASIC V
« Reply #44 on: January 11, 2014, 11:21:11 AM »
I really couldn't give a fig about android at this point in time, nor linux for that matter, for desktop PC's, Windows ( like it or not ) is still where the majority of systems are! Once Napoleon is complete for Windows, then MS DOS (because I have a soft spot for it, and it's my benchmark for the portability of my generic code) then I'll do a Linux port, Linux is a very good but minority operating system !!

I also think if you persist in resurrecting the original code you'll cause more harm than good !
so I hope as you said earlier this is just for your own entertainment !!

I know of other problems you will encounter along the way! if you persist. As I have told you privately I do not intend to do a linux or android port though you by proxy. I had hoped that pointing out the non deterministic nature of Escape key detection in the original, would have indicated the magnitude of the task of making Brandy complete and just as importantly stable.  In addition  Brandy never had complete VDU handling or sound support except under RISC OS where these features are supplied by the operating system.

I suggest you download rpcemu and a RISC OS 5 image from RISC OS open and fully acquaint yourself with BBC BASIC before you proceed any further. It is absurd having someone who openly admits to not being a BBC Basic programmer, trying to port a BBC Basic clone.

I have already wasted too much of my life on your lunacy, I think you just like winding people up  :(
This is my last post in this thread, as far as I'm concerned this issue is closed.