dflat language update

This is the best place to discuss about the various Oric operating systems like Sedoric, Randos, FT-Dos, and others, as well as serious software, utilities, word processors, disassemblers, etc... that runs on oric computers.
User avatar
6502Nerd
Pilot Officer
Posts: 111
Joined: Thu Oct 08, 2020 9:48 pm
Location: Leicestershire, UK
Contact:

Re: dflat language update

Post by 6502Nerd »

Thanks jpberin for your comments and yes you saw the funny big in the comment, I didn't notice until now! :lol:

Thanks for your thoughts on the syntax - I did try to keep it relatively light with structured programming support. Long variable names are all tokenised so they all take the same amount of space in the program and same speed to access.

Talking of speed - yes dflat is a lot faster than Oric BASIC (on average seems about 3 times faster), but I do not think it will be faster than C. To do this there is a big compromise on number handling - dflat is integer only.

But adding the inline assembler I hope makes up a little for not having floating point - and of course provides the ability for extra speed when needed. For example, rax used the inline assembler in the 'Explorer 7' game for hires screen horizontal scrolling.

Due to being a structured language, things like recursive algorithms are easy to implement - see this example of Sierpinksi triangles :-)


Thanks again for taking the time to write and many thanks to rax who has been quite productive with dflat, I am go very grateful :-)
Last edited by 6502Nerd on Sun Jan 31, 2021 9:19 pm, edited 1 time in total.
User avatar
Chema
Game master
Posts: 3014
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Re: dflat language update

Post by Chema »

I must say this is really impressive. Definitely something we should be able to load in overlay ram from disk or use it from a custom cartridge.

Amazing work!
User avatar
6502Nerd
Pilot Officer
Posts: 111
Joined: Thu Oct 08, 2020 9:48 pm
Location: Leicestershire, UK
Contact:

Re: dflat language update

Post by 6502Nerd »

Chema wrote: Sun Jan 31, 2021 9:06 pm I must say this is really impressive. Definitely something we should be able to load in overlay ram from disk or use it from a custom cartridge.

Amazing work!
Thank you Chema! I know you have done fantastic things for the Oric so I'm delighted for the kind words from you! :-)

Indeed, something Dbug also recommending is to have disk option for this. Currently I test on a real Oric-1 with an expansion breadboard I created for this purpose, and on Oricutron emulator. I think there may be utilities in OSDK to help with this - I will investigate as part of the next updates (some bugs and a little space optimisation).
User avatar
rax
Flying Officer
Posts: 193
Joined: Tue Jul 24, 2018 3:16 pm

Re: dflat language update

Post by rax »

Hello :)
Here are the mistakes they saw and I managed to write down (some of the things may work properly, maybe i just mistake in writing):

-too sensitive keys. I have a problem when I use the SHIFT and other key. Every time i want to write " is displayed "'

-as said above, by pressing the key, program starts running slower . You can try this on the PIX program by removing the line with poke 0x5a, 0

-when a long line is entered, the line accepts without error, but is not saved. for example:
10 data 12,12,12,12,12,12,12,12,12,12,12,12,12,12,12,12,12,12,12,12,12,12,12, 12,12,12,12,12,12,12,12,12,12,12,12,12,12,12,12,12

-i like the plot command. it is good to be able to place additional attributes with it: color, background, blink, etc, in both modes (TEXT and HIRES)

-the cursor on the screen is switched off with the "cursor (1)" and switched on with the "cursor (0)", maybe it should be the other way around

-it is better to be able to issue a sound signal with a keyboard shortcut (for example ctrl + g) to stop if there is residual background sound

-for ASM can be well called 3 times in the command "asm (2): asm (2): asm (2)", to become automatic

-these commands hold differently on DFLAT and BASIC 1.1: "play 0,1,0,0:sound 1,100,5:sound1,0,0:play7,7,9,5555"

-maybe in the command list, after the line number to have a space even if it is not complicated (10cls -> 10 cls)

-maybe there should be a reverse command of "pixmode", with which to take the current value of "pixmode"

-does not know how to take the value of the CTRL and SHIFT keys

-if a large circle (outside the borders) is made in graphic mode, it freez: "circle 30,50,90". this gives an interesting shape :) : "circle 120,100,50:circle 120,100,300:circle 120,100,200"

-this line gives an error: "println:println"

-these lines are not used correctly, value in $a[0] is missing:
dim a$[5,4]
a$[0]="zero"
a$[1]="one"
a$[2]="two"
a$[3]="three"
println a$[0]
println a$[1]
println a$[2]
println a$[3]

-these rows with a colon at the end cannot be entered (without a colon - works):
if a: b = 5:
elif b: c = 43:
endif

-if entered on the operator INPUT a$: " aaaa", only "aaaa" is entered

-when the first program is entered in the memory and another is loaded with the "tload" code it is mixed :)
User avatar
6502Nerd
Pilot Officer
Posts: 111
Joined: Thu Oct 08, 2020 9:48 pm
Location: Leicestershire, UK
Contact:

Re: dflat language update

Post by 6502Nerd »

*** Some edits to the below to explain work in progress, as yet not released to GitHub ***

Thank you rax for the detailed feedback. I will make brief comments here, not all I think will be possible to address and some are misunderstandings so I need to make documentation clearer!

- Sensitive keys: Yes I have noticed this too. I think I have an idea to improve this, but will need to check on ROM space
** I reviewed this code and it's been updated a lot, so now the problem of the shift/ctrl key sensitivity is gone - I have found it much better to use also

- Pressing keys causing slow down: Indeed, this is noticeable, hence use the poke for game loops. But I will look again at the scanning code. I do it differently to the Oric ROM, but I thought my code was no worse.. need to look again.
** Oh dear, I review the keyboard scanning code and I had made a dog's dinner of it!! So now it is refactored and work much faster than before. In fact it is so good now the special poke is not really needed - I tested Explorer 7 and my own Tetris game and it feels very good. A for loop to 10000 is about 20% faster!

- Long lines not saved: Yes you are right on this, a known 'feature'! Generating errors takes more ROM space - but this is probably worth to sort out, will look at it.
** Will generate a syntax error if too many characters are typed in to the line buffer

- Plot command: Glad you like it :-) ROM space is again the enemy - but a good idea if I can find space, but I also need to keep things simple for speed purpose.
** Still looking at this. I think it will be difficult without a lot more code. Alternative idea is to have a 'fill' command which works a bit like the Oric BASIC one, which should help with hires drawing (if I can fit it in!)

- cursor keyword: I get this is possibly confusing, but the reason I do it this way is that the cursor inhibit flag is actually a value which gets incremented and documented across some graphics routines in ROM (e.g. scrolling). Hence it allows nesting of inhibit calls. Maybe the keyword should be called 'curoff' which better represents the flag? Or I could look at the whole part again, might even save some bytes.

- keyboard sound signal: Good idea! If I can find space I will look at this :-)
** I have added the ctrl-g to make a short ping sound, which also resets the sound chip!

- asm called three times: This is tricky because the inline assembler can be used as a macro assembler e.g. call a procedure which assembles more code like a macro expansion. It would be ideal, but not sure how - will think further on it though :-)

- play keyword: Yes unfortunately the play keyword is not exactly the same as in the normal Oric ROM. Reason is again for space - I simply take the values here and send to the AY-3-8910, which is different to the Oric ROM. I will look again, but fear that ROM space will be the issue!

- auto space after line number: Good idea - will see if space allows :-)

- read pixmode value: Good idea - will see if space allows :-)

- reading ctrl and shift keys: Indeed there is no way to read this apart from write your own asm routine. Will see if possible and space allows.
** Looking in to extending the 'stick' command to add ctrl and shift detection :-)

- large circles: There are indeed multiple 'features' here :-D First, I only use byte values to calculate the circle so more than about 70 pixel radius, it does not look much like a circle, and I don't think I will be fixing this due to space. The issue of circles outside of screen bounds is also a problem of ROM space - but I will take a look at this, might be possible to check each point for bounds before plotting without losing too much speed and space.
** The pixel plot routine checks boundary (using low byte only) : 0<=x<=239 and 0<=y<=199. The slow down is not really significant. No error is generated, it will just not draw the circle but as it's a single byte check, will not detect underflow and overflow (but at least will not corrupt memory).

- println:println : Yes you found an error that I should try to fix. Workaround now is to do the following; println "":println ""
** I think this is now fixed :-)

- dim a$[5,4]: I should be clearer - but arrays start from index 1 not 0 :-) so in this example, start with a$[1]="zero" and so on. Index zero has a special purpose internally, and probably the code is corrupting memory by doing this :-O

- colon at end of line: Yes this is a restriction, dflat expects a statement after a colon - but not sure of why this style is desirable?

- input a$: Not sure I have understood the problem? If you type in the quotes, it is correct for it to be captured as part of the input - or something else you are raising?

- tload multiple times: tload behaves as if each line was entered at the keyboard and then processes - so yes indeed you can tload one program, then tload another program and it will merge the line numbers. This is intended as I thought it would allow the creation of a "library" - so it means you can create useful routines and then load in other programs on top! To help with this. there is also a 'renum' keyword so you can move program lines before tloading. Of course the workaround is to first 'new' before loading the next program :-)

I am very grateful for your use of dflat and providing this feedback. As you will note, space is very limited, so might be impossible to address all of this, but I will look in to it all and see how much can be done for the next release :-)
Last edited by 6502Nerd on Mon Feb 08, 2021 10:26 pm, edited 1 time in total.
User avatar
rax
Flying Officer
Posts: 193
Joined: Tue Jul 24, 2018 3:16 pm

Re: dflat language update

Post by rax »

I hope that I helped :)
User avatar
mikeb
Flight Lieutenant
Posts: 282
Joined: Wed Sep 05, 2018 8:03 pm
Location: West Midlands, UK
Contact:

Re: dflat language update

Post by mikeb »

6502Nerd wrote: Mon Feb 01, 2021 10:38 pm
- dim a$[5,4]: I should be clearer - but arrays start from index 1 not 0 :-)

- input a$: Not sure I have understood the problem? If you type in the quotes, it is correct for it to be captured as part of the input - or something else you are raising?
It seems like the confusion over array-counting is the old one where everyone learned in BASIC (count from 1) and then moved to C (count from 0) ...

The "input a$" one -- I interpret that as when the user types SPACE A A A A RETURN, A$ only contains "AAAA". The space is being eaten on input, which may not be desireable.

It seems you may need a bigger ROM. Or, do an "Uncle Clive" and make a bodgepack with a ROM hanging out the back -- it worked for the early QL/Spectrums. :)
User avatar
6502Nerd
Pilot Officer
Posts: 111
Joined: Thu Oct 08, 2020 9:48 pm
Location: Leicestershire, UK
Contact:

Re: dflat language update

Post by 6502Nerd »

Ha yes, I remember making the transition from 1 index to 0 index too! :lol:

Regarding the input a$ query - I just tested that and it is not eating spaces, so not yet sure what this is. :?:

I ported dflat from my homebrew computer, which had 64KB of ROM! In the design of that, I had 2 port pins of one of the 6522s to switch in one of four 16KB ROM banks. So plenty of space for dflat plus extra bonus of SD card handling and FAT16 filesystem compatibility.

Porting from that to the Oric was a squeeze as you can imagine - also going from 65c02 to 6502, which adds problems like no instructions to push and pull X,Y registers on and off stack, and only indexed indirect addressing modes. So it takes a few more bytes to do the same on 6502 compared to 65c02 - not much, but still when I'm down to a handful of bytes, it hurts!

My motivation for keeping it all in one 16KB ROM is so that it will work on a standard Oric-1 or Atmos, without relying on banking hardware.. :)
User avatar
6502Nerd
Pilot Officer
Posts: 111
Joined: Thu Oct 08, 2020 9:48 pm
Location: Leicestershire, UK
Contact:

Re: dflat language update

Post by 6502Nerd »

rax wrote: Tue Feb 02, 2021 11:47 am I hope that I helped :)
Dear rax - I really appreciated the creativity and getting to know the language which resulted in some nice programs! Yes your feedback helped a lot, I am looking at all of them to see how and which I can address in the next release, which will probably take a couple of weeks. :)
User avatar
ibisum
Wing Commander
Posts: 1646
Joined: Fri Apr 03, 2009 8:56 am
Location: Vienna, Austria
Contact:

Re: dflat language update

Post by ibisum »

So plenty of space for dflat plus extra bonus of SD card handling and FAT16 filesystem compatibility.
+
My motivation for keeping it all in one 16KB ROM is so that it will work on a standard Oric-1 or Atmos, without relying on banking hardware..
May I suggest that new Oric hardware peripherals, which extend the ROM/RAM banking facilities immensely, might also be a target for your near horizon .. ? At least keep an eye on extending dflat with new slots, because I think this is kinda of a thing with newGen Oric hardware ..
User avatar
6502Nerd
Pilot Officer
Posts: 111
Joined: Thu Oct 08, 2020 9:48 pm
Location: Leicestershire, UK
Contact:

Re: dflat language update

Post by 6502Nerd »

ibisum wrote: Tue Feb 02, 2021 10:14 pm May I suggest that new Oric hardware peripherals, which extend the ROM/RAM banking facilities immensely, might also be a target for your near horizon .. ? At least keep an eye on extending dflat with new slots, because I think this is kinda of a thing with newGen Oric hardware ..
Absolutely, if there is interest!

I know how to do this already from the approaches I used in my homebrew computer design, which involved lots of auto-generated vector tables which were invoked in cross-bank calls.

It was a lot of fun to design, and if I can reuse it on Oric, great because then I would bring the SD Card drivers and FAT16 filesystem in as well.. which I am particularly pleased with as I created it completely from ground up for fun, and needed much research on those subjects!

Just for now I will focus on the 16KB restriction to get a stable and '1.0' kind of situation :-)
User avatar
iss
Wing Commander
Posts: 1641
Joined: Sat Apr 03, 2010 5:43 pm
Location: Bulgaria
Contact:

Re: dflat language update

Post by iss »

6502Nerd wrote: Tue Feb 02, 2021 10:50 pm Just for now I will focus on the 16KB restriction to get a stable and '1.0' kind of situation :-)
My 2 cents: Do not consider that all Orics have 16KB available for external ROM. Those with two 2x64 ROM chips probably are not "fixed", so only 8K usable. But maybe I'm too pedantic...

And here @rax goes again - new hot code:

Code: Select all

def_s()
hires
_circ(99,99,99)
enddef
def_circ(x,y,r)
local n
circle x,y,r
n = r/2
if n > 3
_circ((x-n),(y-n),n)
_circ((x+n),(y-n),n)
_circ((x-n),(y+n),n)
_circ((x+n),(y+n),n)
endif
enddef
And the result:
image_2021_02_02T21_44_28_355Z.png
Please, someone stop him! :lol:
User avatar
6502Nerd
Pilot Officer
Posts: 111
Joined: Thu Oct 08, 2020 9:48 pm
Location: Leicestershire, UK
Contact:

dflat - version 0.12

Post by 6502Nerd »

Hello, a quick update on dflat, version 0.12 (which I still count as beta) now on GitHub https://github.com/6502Nerd/dflat

Bugs fixed:
- If a line that is too long is entered, now gives a syntax error
- 'println:println' behaves as expected (not a syntax error)
- cls command cleared too many rows, writing in to ROM space.

Improvements:
Keyboard;
- Sensitivity improved, no noticeable slow down during execution
- Pressing CTRL+G makes a 'ping' sound, silencing any current sound
circle/line command;
- if the circle or line goes out of 8-bit bound, those pixels are not drawn
- lineto x,y - new command draws from end of last line
- changed make.bat (does not generate ROM message build.s)
- minor optimisations
User avatar
xahmol
Flight Lieutenant
Posts: 437
Joined: Sun Jun 28, 2020 7:32 pm
Location: Utrecht, The Netherlands
Contact:

Re: dflat language update

Post by xahmol »

Still following this thread with interest!
Quick question: would it be possible/easy to have dflat as ROM for the Twilighte board/Orix using this? http://orix.oric.org/build-a-rom-for-orix/
(background on Twilighte board: http://orix.oric.org/twilighte-board-v0-6-user-manual/

Because if possible, that would actually be a very easy way to use it on real hardware (provided you have an Atmos that works with the Twilighte board, which still seems very random. For me, one Atmos works, one Atmos very unstable)
User avatar
6502Nerd
Pilot Officer
Posts: 111
Joined: Thu Oct 08, 2020 9:48 pm
Location: Leicestershire, UK
Contact:

dflat - version 0.12

Post by 6502Nerd »

xahmol wrote: Mon Mar 08, 2021 3:17 pm Still following this thread with interest!
Quick question: would it be possible/easy to have dflat as ROM for the Twilighte board/Orix using this? http://orix.oric.org/build-a-rom-for-orix/
(background on Twilighte board: http://orix.oric.org/twilighte-board-v0-6-user-manual/

Because if possible, that would actually be a very easy way to use it on real hardware (provided you have an Atmos that works with the Twilighte board, which still seems very random. For me, one Atmos works, one Atmos very unstable)
The Twilighte board looks amazing, although I do note it's rather picky about what hardware is needed..
I scanned the documentation - looks like it is possible to load a ROM. The GitHub link contains the build ROM in the following folder
https://github.com/6502Nerd/dflat/tree/ ... lator/roms
It is called dflat.rom
I think also the dflat.pch file might be needed, but not sure (this is the 'patch' file which allows for fast load/save to PC in Oricutron emulation)
If you have one of these boards you could try it!
I also noticed that it is possible to try this board under Oricutron emulation - I will have a look at this too!
Thanks for your interest :-)
Post Reply