dflat with native LOCI support

This is the right place to discuss on how to implement hardware vsync, adding a VIA or AY chipset, puting multiple roms, or how to design a new flash expansion card.
User avatar
6502Nerd
Flying Officer
Posts: 137
Joined: Thu Oct 08, 2020 9:48 pm
Location: Leicestershire, UK
Contact:

dflat with native LOCI support

Post by 6502Nerd »

Hello everyone - hope your Christmas has been wonderful.

I would like to announce that in between the festivities I have made a new version of dflat with full native support for LOCI. Before Christmas I had made some progress but had not made anything available on GitHub as I needed to tidy up other parts of my repo and adding scripts to help editing sessions between PC and Oric.

The new ROM only supports LOCI (not even tape is supported due to ROM space). This ROM uses the folder called 'dflat' in the root of the SD card as its filesystem.

dflat for LOCI supports:
- Loading and saving files
- Moving between folders
- Directory listing (now fixed the size issue)
- Deleting files

It is super easy to get started on dflat thanks to LOCI:
- Simply copy the dfloci.rom and the software/dflat folder to your SD card
- Plug SD card into LOCI
- Plug LOCI into your Oric (I have tried with Atmos and Oric-1)
- Select dfloci.rom
- Load, save and navigate directories from dflat

https://youtu.be/kh5h8KwNI7I

All files etc. are available in my GitHub : https://github.com/6502Nerd/dflat

Do let me know if the short video I have posted helps or any suggestions.

Also note there is a set of Wiki docs on using dflat here : https://github.com/6502Nerd/dflat/wiki
User avatar
ibisum
Wing Commander
Posts: 1918
Joined: Fri Apr 03, 2009 8:56 am
Location: Vienna, Austria
Contact:

Re: dflat with native LOCI support

Post by ibisum »

Awesome! Do you think you might add the ability for dflat to somehow send LOCI "mount /sd/1.dsk [a,b,c,d]" style commands at some point?
User avatar
6502Nerd
Flying Officer
Posts: 137
Joined: Thu Oct 08, 2020 9:48 pm
Location: Leicestershire, UK
Contact:

Re: dflat with native LOCI support

Post by 6502Nerd »

ibisum wrote: Tue Dec 31, 2024 12:53 am Awesome! Do you think you might add the ability for dflat to somehow send LOCI "mount /sd/1.dsk [a,b,c,d]" style commands at some point?
Thank you!

So when using the native LOCI API, I did look at how to mount, but due to the ROM size restriction, I dropped this in favour of an assumed mount point of 1:/dflat for the filesystem. However the 1: device cannot be assumed for example if you have other devices (e.g. mouse) then it could be 2: or 3:

To allow for this, you can hold down keys 1 through to 9 on booting dflat and this will be the default device number instead of 1:

Hope that keeps dflat flexible enough for the various ways in which people may be using LOCI with other devices attached..
User avatar
xahmol
Squad Leader
Posts: 611
Joined: Sun Jun 28, 2020 7:32 pm
Location: Utrecht, The Netherlands
Contact:

Re: dflat with native LOCI support

Post by xahmol »

Not sure if you have ROM space for it, but I tried to solve valid device detection with this:
https://github.com/xahmol/locitest/blob ... oragecfg.c

Detects the storage devices attached with MSC in their name (mass storage devices) and creates an array of drives that are valid targets or not.

In Loci file manager (repo is not yet public, will be public on first working alpha) with this the first valid drive will be selected, with the ability to switch to next valid.
User avatar
6502Nerd
Flying Officer
Posts: 137
Joined: Thu Oct 08, 2020 9:48 pm
Location: Leicestershire, UK
Contact:

Re: dflat with native LOCI support

Post by 6502Nerd »

That's nice work, not too long at 77 lines of C.. but I am down to single digit bytes in the ROM so unless I remove a stack of things I don't think I can use it!

Still, it's great to see so much being done for LOCI, fast becoming an must-have add-on for Oric users!
jsk
Officer Cadet
Posts: 46
Joined: Mon Jun 29, 2020 10:11 pm

Re: dflat with native LOCI support

Post by jsk »

6502Nerd wrote: Tue Dec 31, 2024 12:35 am Hello everyone - hope your Christmas has been wonderful.

I would like to announce that in between the festivities I have made a new version of dflat with full native support for LOCI. Before Christmas I had made some progress but had not made anything available on GitHub as I needed to tidy up other parts of my repo and adding scripts to help editing sessions between PC and Oric.
I've looked at the sources, and it's quite impressive in small size. I'm wondering if it could be generalized and be an "alternative" small/native API in the loci-library?

I'm all for starting in C-code in CC65, and that's how I plan to do my Loci projects, but piece by piece may replace it with asm for size...

Anyway, I was wondering why there was no .tap-file for running dflat? I'm planning to do both tap/ROM variants of my language.

Also, I have a question regarding your line draw and circle commands if these are same/similar as the LineBench source? I've coded my own in C, but they are a tad slower than yours, still faster than the BASIC.
User avatar
6502Nerd
Flying Officer
Posts: 137
Joined: Thu Oct 08, 2020 9:48 pm
Location: Leicestershire, UK
Contact:

Re: dflat with native LOCI support

Post by 6502Nerd »

Hello jsk

Sorry for the late reply from me - I didn't notice that I had been logged out of the forum and didn't see the notifications!

The LOCI routines are quite small indeed to fit into the very little room left in the 16KB ROM space which is needed also for dflat. You are free to use them for a generic minimalist library if you want :)

There is no .tap file support due to space - My 'regular' dflat ROM contains the .tap load and save capability but I use conditional assembly to generate LOCI version without this and vice-versa. If you have space in your ROM then you are welcome to use these tape routines if it helps!

The circle and line commands are not based on LineBench (I didn't hear of this until now). I hand coded them so I could optimise for speed on the Oric. Both routines rely on a fast pixel plotting routine called gr_point which uses table look up to map x,y to hires address and bit mask.

The circle routine compromises on accuracy by using only 8 bit calculations and only calculating 1/8 of a circle then using symmetry to plot the other points! The compromise means circles only look right up to about radius of around 70 pixels - but I didn't think I would often need bigger than this.

Hope that helps and good luck with your project, interested to see the progress!
Post Reply