ZX Spectrum Next (and compatibles) QL Core now available!

[QuantumLeapGR]

Hi all;*
for those of you who have a ZX Spectrum Next (Issue 2 - SLX16 or Issue 4 - A7) -or compatibles like the N-Go and the XBerry Pi- the first version of the QL Core is now available as part of the standard System/Next distribution. Features (An asterisk denotes a feature only present on Issue 4 machines)
68K @ 22MHz
256 colour mode via Minerva second screen (Not Aurora compatible - yet)
1920 Kb of RAM
HDMI and VGA output
16 colour MODE 8 (Lion Gold compatible)
QIMI Mouse
ESP for WiFi
RTC
QLSD compatible with additional software to read and write FAT32 drives
Memory mapped MDV emulation (only supports QLAY mdv)
Joystick ports which can be also used as I/O
QL Net via external adapter
AY/YM chip (*) Q-Sound
Digital Audio (*)
90 sprite sprite engine (*)

Navigate to www.specnext.com/latestdistro/ to downlod it

Note: it's not YET compatible with either Aurora modes or SMSQ/e

[Popopo]

Beautifil!!!
thank you!

[Peter]

QLSD compatible with additional software to read and write FAT32 drives

I presume these are Leon's programs also distributed with his QLion hardware.
Are they open source, so they could be adapted to QL-SD and Q68 also?

[lliont]

Well, I am the final core author.
There was a core for the KS1 next that lacked many things as QLSD, the hdmi and native mouse-keyboard support, it was based on an old mister core and I was asked if I could adapt it to next and also to the KS2 next.
So I made some changes to the core and ram access, made the mechanism to load rom and drivers from the sd and added native keyboard, fixed the mouse, joysticks, added hdmi, and QLSD (same as QLion) and added more features as serial connection to esp, rtc, sprites, AY-YM sound, digital samples, NET suport (Martyn did the most work, made the driver and external interface), 256 colors....

The core was developed in a KS1 next machine and then ported to the KS2 next and there I added some features, so KS1 lack sprites and digital samples and has a different hdmi resolution.

Many things where ported from QLion and others I did for next where ported to QLion. QLion uses different code but they share many features and many programs will work on both machines maybe with little alterations, i.e. the 256 256x256 color mode is in different address and QLion supports also 512x256 in 256 colors.

The source code will be made available soon.

[lliont]

QLSD compatible with additional software to read and write FAT32 drives

I presume these are Leon's programs also distributed with his QLion hardware.
Are they open source, so they could be adapted to QL-SD and Q68 also?

So you are correct they are my programs, I can give you the source code to adapt to your machines, after all I made the mouse driver for QLion by studing your code.

[Peter]

The source code will be made available soon.

Sounds good. Already one curious question: Can the FAT32 tools deal with fragmented files?

[lliont]

Fat has no limitations, it also takes paths, I used the FATFS library (as suggested by Phoebus)
http://elm-chan.org/fsw/ff/00index_e.html

I'm not sure I understand the question though, It copies file between fat and already mounted images. So the images have to be as ql-sd needs them to be.

i.e. EW SCOPY;' \testdir\test.txt Win2_test_txt'

[Peter]

Fat has no limitations, it also takes paths, I used the FATFS library (as suggested by Phoebus)

Okay, I was asking just in case you wrote the code yourself, instead of using FATFS or mtools.
I wrote some basic FAT32 stuff myself for size reasons, which is not that capable.

I ported mtools to the QL side for various SD card interfaces, based on an older version which had problems with large cards.
I wonder it it makes sense to look at mtools again.

[Peter]

I'm not sure I understand the question though, It copies file between fat and already mounted images. So the images have to be as ql-sd needs them to be.

The native filesystems containers, yes. But other files on the FAT32 side could well be fragmented.
I would not have asked, if I knew that you use existing open source libraries, which obviously can handle it.

[Peter]

[...] after all I made the mouse driver for QLion by studing your code.

Hopefully you didn't study my initialisation code though. It contains unclean timing loops und seems overly picky with mice. Deserves a total rewrite. But my LRESPR driver is okay.