richpl / PyBasic

Simple interactive BASIC interpreter written in Python
GNU General Public License v3.0
170 stars 46 forks source link

PyBasic Fork #9

Closed JiFish closed 3 years ago

JiFish commented 3 years ago

Hello! Thank you for releasing the source of PyBasic under an open license.

I have forked PyBasic for my fantasy computer side-project. Unfortunately, a fork is necessary as I have to add commands for manipulating the 'screen' etc. I have cheekily dubbed the fork "JiBASIC" because I couldn't resist the pun.

But I am tempted to submit a patch to PyBasic to help disentangle print() from the BASICParser and Program classes. This will help me pull upstream fixes and changes from PyBasic, and allow me to push fixes and more generic additions back here more easily. Would this be something you'd be interested in?

On the subject of pushing upstream, I've already added a version of the CHR$() function, and am planning to add convenience functions for string manipulation and more, interested in those? I'd understand if the scope of your project is limited to the basics and you don't want to maintain my feature creep.

Here's a little animation of my WIP

arti_2

richpl commented 3 years ago

Hi Joseph

Wow, I'm impressed with what you've done already! Flattered that you are using PyBASIC. It would be very interesting to find out a bit more about your fantasy computer project and what you are setting out to achieve.

Generally I am open to patches/pull requests with a few caveats. First off I'd like to maintain the architectural integrity of the code. Not quite sure what you mean by disentangling print(), but if it doesn't introduce any awkwardness into the code structure then I'm potentially open to that.

I'm very happy to add additional functions. The only thing I'm trying to avoid is introducing any platform dependent features into the code in order to maximise portability across operating systems (for example, not sure how your color function works above and whether that would work across platforms). If you do suggest some portable additions, it would also be very helpful if you could make corresponding updates to the readme file and I'll be happy to accommodate them.

JiFish commented 3 years ago

It would be very interesting to find out a bit more about your fantasy computer project and what you are setting out to achieve.

Just in case you aren't familiar with fantasy consoles/computers: the idea is not to emulate any real system, but create something new with limitations in the style of retro machines. For recreational programming, game jams, the challenge etc. I wanted a FC that reminded me of the British 8-bit micros of my youth: Amstrad CPC, ZX Spectrum etc. Artemis will be very simple in comparison to most other FCs. The UI is driven by pygame and there's not very much to it.

The challenge here will be to write games in BASIC and using only text-modes. Currently you get a 40x25 characters screen with 16 redefinable colours. I'm planning to add a 80x25 char, 8 colour mode and maybe one or two others. The palette is 5-level RGB, giving 125 colours to choose from total. Inspired by (but slightly more generous than) the unusual 3-level RGB palette of the Amstrad CPC. There's a 256-character extended-ASCII character set. The characters can be redefined.

I probably won't put any artificial limits on available memory or processing. The real gauntlet being laid down is the UI.

I'm still at the tinkering phase at the moment. I need to clean of lot of stuff up, but I am hoping to get a version on github soon.

Not quite sure what you mean by disentangling print(), but if it doesn't introduce any awkwardness into the code structure then I'm potentially open to that.

Thinking about it, the only thing that's bugging me is that Program.list() prints output directly. If instead it returned the program listing and interpreter.py printed it, then the forked version of program.py could be the same as this version. Which would be nice, but it's not really a big deal.

I'm very happy to add additional functions.

Grand. How would you prefer it? One big patch, or separate pull requests for each function? I already have a few which are probably good to push upstream: CHR$, ASC, MID$ and MOD.

richpl commented 3 years ago

Whatever works for you, happy to deal with pull requests for each function or as a batch!

JiFish commented 3 years ago

Modes and music test for the fork. Demonstrates having to choose between pixels/on screen colours. Also sound based on the QBASIC / Music Macro Language syntax,

https://www.youtube.com/watch?v=2Q1DfBC3Yvk