Basic Interpreter / Mixing of screen modes

Topics related to the API, programming discussions & questions, coding tips, bugs, etc. should go here.
majorsky78
Posts: 15
Joined: Tue Jul 07, 2009 5:23 am

Basic Interpreter / Mixing of screen modes

Post by majorsky78 »

Hi!
I just started working a little bit with uzebox and emulator. I took the ubasic interpreter from Adam Dunkels (http://dunkels.com/adam/ubasic/) and integrated it into the demo for Videomode9.
Next step will be to change the source of the RAM sourcecode from RAM array to SD card. When the current line of basic code is finished, I will read in the next line of code from SD card... and so on.
Afterwards, I have to add some additional basic commands... also string variables are still missing, I think.
I will add a work-in-progress HEX file and source here, when it makes sense...

Ok. Now while working on the basic things, the following question came up in my mind. When I have a working basic interpreter (in some years ;-) , using it only in text mode, without any graphics will not be so funny.
Therefore, I thought about the following two possibilities:
1) Switch between Graphic Mode 9 and 8 by using a basic command.
Basically, this should be possible. VRAM must be cleared and graphic mode must be switched to some other "render tile" function. But it should be possible, am I right?
2) It would be even more cool , if I could say: upper half of the screen is Mode 8 and lower half is Mode 9. How much effort would it be to realize something like this?
CunningFellow
Posts: 1445
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: Basic Interpreter / Mixing of screen modes

Post by CunningFellow »

Quite feasible technically. The render_line called could be changed at any point during the screen. How to integrate that nicely into the kernal/api is probably a decision for uze.

How about a mixed text and graphics mode? I remember locomotive basic on the Amstrad I could draw lines across the text on the screen.
majorsky78
Posts: 15
Joined: Tue Jul 07, 2009 5:23 am

Re: Basic Interpreter / Mixing of screen modes

Post by majorsky78 »

For Mode 8 with 120x96 pixels, showing some simple bitmaps (thinking of a graphics adventure) could be possible. But text with 120x96 pixels would only be about 20x12 characters, which is not so much.
High resolution Mode 9 really looks good for text. Problem here is, that user defined graphics is not possible because of flash code tiles.
Second problem is, that code tiles really need much flash space, but it should be ok, if we just use A-Z and 0-9.

For all other graphic modes, showing text is ok, but user defined graphics is only possible with RAM tiles and as the number of them is quite limited, this is also not the right approach,I think.

Switching between Mode 8 and 9 or mixing them would be quite nice, I think...
CunningFellow
Posts: 1445
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: Basic Interpreter / Mixing of screen modes

Post by CunningFellow »

How does the text look in mode6 on "vector game".

I cqn do that in 4 colours in a mixed text and graphics mode.

Also a single colour per cell plus attribute "spectrum" mode is doable.
majorsky78
Posts: 15
Joined: Tue Jul 07, 2009 5:23 am

Re: Basic Interpreter / Mixing of screen modes WIP

Post by majorsky78 »

Hi there!

Below, you can find a first version together with some questions...
The ZIP file, you can unzip in the "demos" folder of the trunk. With the batch file "compile.bat", you can compile the files.
During porting the ubasic interpreter, I found some strange things...

1. "20140214_uzebasic_working": This is the working version. It has a sample basic program "23 matches" in program memory. When you start it, you will first find a dummy filebrowser, copied from Uze8. When you press <A>, the sample program will start and work...

2. "20140214_uzebasic_notworking": In this version, only one thing is changed. For the token data structure, which is saved in flash memory, the data type of "token entry" is changed from byte to word. And now... the emu directly crashes.
And I don't know, how to debug this?!

Structure in tokenizer.h
struct keyword_token {
#if USE_PROGMEM
// um via strxxx_P zugreifen zu koennen, muss eine feste Laenge vorgegeben werden
char keyword[MAX_KEYWORD_LEN+1];
#else
char *keyword;
#endif
// not working modification
/*unsigned char*/ int token; // => "unsigned char" is working, "int" not working
};

Structure filled in tokenizer.c, starting at line 76...

Does anybody know, how I can debug such things?

3. Debugging with avr-insight:
I tried debugging with uzemu, gdb support and avr-insight. The file seems to load and debug correctly, but function calls are not really performed... Don't know how to describe this better.
Is there anybody using gdb support of uzemu?

4. I tried to generate a new tileset for Mode 9. It is working, but the background color is not working.
I am using the current gconvert of the binary distribution. Interesting: Even if I convert the example tileset for Mode9Demo (generate a new "fonts6x8.inc"), background color is NOT working anymore for Mode9Demo. Only if I take the original fonts6x8.inc from SVN, the background color effect is working?!

Ok... I think that's all for the moment.

By the way... I still have enough RAM to increase VRAM. I would have enough VRAM even for Mode 8 (120x96/4 = 2880 bytes) and Mode 9 (60x28=1680 bytes). Therefore switching of videmode would eventually be possible... but I don't know, how to realize...

Kind regards and thanks for any hint about the issues above!
Andre
Attachments
20140214_uzebasic_notworking.zip
(1.73 MiB) Downloaded 242 times
20140214_uzebasic_working.zip
(1.73 MiB) Downloaded 246 times
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Basic Interpreter / Mixing of screen modes

Post by uze6666 »

Somehow I missed this topic! You can't mix mode 8 and 9 since they are mutually exclusive in terms of code generated at build time. A custom video mode is what is needed for a basic interpreter. Using CunningFellow idea of a Spectrum mode sound great or you could use also mode 6. The ramtiles can be used as a redefinable character set. You can do pretty intricate graphics too.

Not home now so I can't check the code, but I could ran the HEX. Cool, a running basic interpreter! Need...to..do...a...keyboard...interface... 8-)

I think there is a bug in gconvert's mode 9 "codetile" generator. I'll have a look.

For debugging I use Uzem GDB with Eclipse, I really despise Insight. Check the wiki, there's info on how to set it up. It's a little tedious but afterward it is much easier to debug. One think you may have to do is change the optimization from -Os to -O0 in your makefile. Debugging seems to have issues some times with optimized code.
CunningFellow
Posts: 1445
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: Basic Interpreter / Mixing of screen modes

Post by CunningFellow »

MajorSky78,

I can do you a custom mode that splits 360/288 pixels across monochrome text only at the bottom with some other mode (bitmap etc) at the top.

The monochrome only part could have full 256 ASCII/Code9 whatever font unlike the full colour mode9 that would take too much flash.

I could possibly do a 288/256 pixel 4 colour mode that has 128 ROM tiles and 128 RAM tiles.

Or the already mentioned spectrum like mode with char/attribute.

What do you think suits you best?
majorsky78
Posts: 15
Joined: Tue Jul 07, 2009 5:23 am

Re: Basic Interpreter / Mixing of screen modes

Post by majorsky78 »

Thanks for the hints...
I will change optimization for debugging and try again. I used avr-insight, because it was already there... I also don't like it really.

For the video mode, I have the following requirements:
- don't use too much RAM
- "high res" text mode
- be able to load user defined graphics (picture) from SD card

For the RAM, I am not so sure, what will be used by the different things, you proposed.

For the user defined graphics, I see two possiblilties:
a) Something like Mode 8:
+ 4 colors available
+ "full screen" graphics could be loaded
- 120x96x2bits = 2880 bytes for VRAM.
- not suited for text (120 pixels would only be 20 characters)

b) 128 RAM tiles / 128 ROM tiles
+ 4 colors available
+ graphics will be for example 16 x 8 tiles => How big will the part of the screen be? Rest can still be used for text
+ also a small graphics (12 x 8 tiles) and some user defined characters would be possible
+ text would be quite ok (288 pixels = 48/36 characters (6/8 pixels assumed per tile))
+ 128 ASCII characters would be possible, big ("ABC") and small ("abc") letters => This is not really possible for Mode 9, because of flash needed
? How much RAM and flash is needed?

c) 360/288 mode
+ Upper part monochrome bitmap
+ lower part text
? Would the vertical border between text and bitmap movable or fixed?
=> If it is movable, then I think (c) could be as good as (b)
=> It it is fixed, I would prefer (b)
? How much RAM and flash is needed?

But I think I prefer (b) for the moment.
Maybe, you can give some more details for about your proposals...

Kind regards,
Andre

UPDATE UPDATE UPDATE

I tried to find the mentioned problem... I recompiled with "-O0" but used again avr-insight. Now, I could debug - somehow. In the version with 16 bit data in the data structure in program flash, I can see, that already in the SD card functions, which are reading the directory, something is going wrong. When I add a while(1) just before ubasic_init in the main loop, I can see, that the FileBrowser displays an empty directoy.
As mentioned: The only difference between the working and not working version is, that the tokenizer data structure uses 16 bit word instead of 8 bit byte for the opcode. This makes a difference in program memory. It is an offset of 50 to 60 bytes... and suddenly, it is not working anymore.
I will retry debugging with Eclipse...

Uze: For the keyboard input, I think the only possibility is to use RX line of the spare UART, right? I think, it is not possible to connect a PS/2 keyboard somehow, because PS/2 keyboard is generating clock and data pulses of about 10 to 15 kHz. I think, it is not possible to scan this while doing video output...
Maybe, we could use a little AVR to convert PS/2 signals to UART?
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Basic Interpreter / Mixing of screen modes

Post by uze6666 »

I was thinking that BASIC didn't have split screen or commands for it so why not simply make it work the old ways with multiple full-screen video modes, swicthing with a SCREEN command? In any cases did you have a concrete usage of split screen?

Anyhow, I revisited some old code and could produce a 6x8 mono pixels tiles mode @ 5 pixels/clock. Good for a "hi-res" text mode of 48x28, though it's only black & white. There's two way of implementing it, depends on the RAM budget:
1) Pixel data is in flash, but it requires an unrolled rendering loop which consume (a not too bad) 2400 bytes of flash. VRAM size is 48*28=1344 bytes for a 256 character set. Could have 2 banks of 128 each, regular+inverted text.
2) Pixel data is in RAM. Takes 1024 bytes per 128 characters, but they are obviously fully redefinable. VRAM size is 128*8 + 48*28 = 2368 bytes for a 128 character set.

Either mode could be combined with a mode 8 like sub-mode. I was thinking that perhaps this special uzebox mode could allocate vram from the heap so it would allow programs that doesn't required mode8 to use more RAM. Otherwise, VRAM is statically allocated and the size will correspond to the bigger sub-video mode requirement, that is, mode 8 with its 2880 bytes.
Uze: For the keyboard input, I think the only possibility is to use RX line of the spare UART, right? I think, it is not possible to connect a PS/2 keyboard somehow, because PS/2 keyboard is generating clock and data pulses of about 10 to 15 kHz. I think, it is not possible to scan this while doing video output...
Maybe, we could use a little AVR to convert PS/2 signals to UART?
Effectively, I don't think we can connect a PS/2 keyboard to the UART for the reasons you mentioned. I was also thinking of a Attiny but interfacing via one of the SNES ports since it's the only "ports" all Uzebox versions share. So the Attiny would use a UART port (or plain bitbang) in input, listening to the keyboard and shifting out the data via SPI on the SNES controller side.
majorsky78
Posts: 15
Joined: Tue Jul 07, 2009 5:23 am

Re: Basic Interpreter / Mixing of screen modes

Post by majorsky78 »

Hi again,

SCREEN command is possible, for sure! There is no need for mixing...
I just checked out, how many RAM is left. When I turn the music mixer to inline mixing, there is 1684 bytes left with Mode 9, which already has a VRAM of 1680 bytes. So in total, 3364 bytes are there for VRAM (, heap and stack). Therefore, having 2880 bytes for Mode 8 should be possible.
Pixel data for the text mode should also be in RAM.
Allocation of VRAM from heap would be perfect!

But now, I will try to get the debugger running in Eclipse in order to understand, why the program sometimes crashes.
As I have no real hardware at the moment. Could somebody check the two ZIP-files? Are they behaving identical for emulator and real hardware?
Post Reply