LOL, yes, I got as far as testing PRINT "HELLO" before giving up trying to workout where all the various keys got mapped to ... I admire your endurance!
[v1.1] MECB 1MB ROM Expansion Card
Re: [v1.1] MECB 1MB ROM Expansion Card
Excellent - glad that worked. I find it is a valuable debugging tool particularly when working with numerous unknowns.
LOL, yes, I got as far as testing PRINT "HELLO" before giving up trying to workout where all the various keys got mapped to ... I admire your endurance!
LOL, yes, I got as far as testing PRINT "HELLO" before giving up trying to workout where all the various keys got mapped to ... I admire your endurance!
Re: [v1.1] MECB 1MB ROM Expansion Card
Apparently the creativision basic uses the VDP RAM to store programs, this is partly responsible for its slow operating speed. I found an interesting discussion here: https://forums.atariage.com/topic/21959 ... ativision/
Also because of this, graphic programming is not possible in Basic.
The color commands seem a bit crazy too.
I have a port of BBC Basic on the 6809, I'm hoping to have a Bios to use the colour features of the VDP for it one day. I'm not sure what is possible with this chip, seems more biased to native code gaming/graphics (must read the manual).
Also because of this, graphic programming is not possible in Basic.
The color commands seem a bit crazy too.
I have a port of BBC Basic on the 6809, I'm hoping to have a Bios to use the colour features of the VDP for it one day. I'm not sure what is possible with this chip, seems more biased to native code gaming/graphics (must read the manual).
Re: [v1.1] MECB 1MB ROM Expansion Card
Ah, so that's how they overcome the memory limitation.
Just looked up the color command - that is a bit weird but I can see why it is done that way. The colour tables are very closely mapped with the character definitions. I ran into this oddity when I was running some tests via the 6809 and wanted to just randomly write text in different colours but then realised that it wasn't actually all that simple to do that (given the way the VDP works) i.e. you can easily make all instances of a particular character a given colour but it is not as easily to change the colour of a single character on the screen (you basically need a duplicate definition of that character with the colour you want). It's a different approach to what I'm used to where each character on the screen has two bytes i.e. one to define which character you want and the other defines the attributes of the character e.g. colour, flashing, etc). Overall, I found it quite clunky to do things with the VDP (even the sprite handling is very limited i.e. you have to be careful not to have more than a certain number of sprites on the same horizontal line otherwise some will start blanking out). The one plus is that the video memory didn't occupy much space in the memory map (the VDP registers could be used to access the memory indirectly albeit more slowly than you could if it were memory mapped).
Just looked up the color command - that is a bit weird but I can see why it is done that way. The colour tables are very closely mapped with the character definitions. I ran into this oddity when I was running some tests via the 6809 and wanted to just randomly write text in different colours but then realised that it wasn't actually all that simple to do that (given the way the VDP works) i.e. you can easily make all instances of a particular character a given colour but it is not as easily to change the colour of a single character on the screen (you basically need a duplicate definition of that character with the colour you want). It's a different approach to what I'm used to where each character on the screen has two bytes i.e. one to define which character you want and the other defines the attributes of the character e.g. colour, flashing, etc). Overall, I found it quite clunky to do things with the VDP (even the sprite handling is very limited i.e. you have to be careful not to have more than a certain number of sprites on the same horizontal line otherwise some will start blanking out). The one plus is that the video memory didn't occupy much space in the memory map (the VDP registers could be used to access the memory indirectly albeit more slowly than you could if it were memory mapped).