Are you developing a ZX8* program using ZXpand features?

[sirmorris]

Come on, I know at least 2 of you are.

Can we please have a discussion about your needs and desires? You don't need to let any cats out of the bag, but I feel a bit lost trying to imagine what people would need. At the same time people can't be expected to know what is potentially available so ... this thread.

[Lardo Boffin]

I was certainly thinking about it.

For me random file access would be heaven. Being able to specify a position in a file and an amount of data would be awesome. Being able to step through a file and find a specific piece of data (e.g. a record marker) would be a bonus but could be implemented just with basic access by stepping through one byte at a time I guess.

Also fixing the EightyOne emulator so it doesn't always create files read only would be cool.

[1024MAK]

It would indeed be handy if BASIC programs could read or write some kind of data file (even if it is just a binary file without any predetermined format) on the SD card.

Mark

[dr beep]

Only thing I built in is joysticksupport, when there is room.

[Shaun_B]

I might one day progress to making ZXPand software. First though I need a ZXPand.

Thanks,

Shaun.

[Math123]

Very interesting!

I am just ready with sound commands. Data file access is planned.
Have no idea how Joystick interface could look like.

Sound commands are like this:
BEEP time,pitch (compatible to the Spectrum)
PING pitch
WAIT time
And to switch between pitch in Hetz, C0 or MIDI:
PITCHF
PITCHC
PITCHM
And for all people who are familiar with the YM2149 registers:
YM register,value (8 bit)
YMX register,value (16 bit)

Preversion 1.5 with incomplete documentation but some demofiles is ready to download here http://www.swatosch.de/zx81/powerbasic1.5/

[nollkolltroll]

It would be nice to have proper standardized set of API-calls: open/close file, read, seek, write etc. With simple calls, just load HL with a pointer to whatever data struct is needed, and check flags on return. This will make it easy to be compatible with future revisions, just use these API-vectors. BASIC extensions can/should be made by whoever feels the need. Concentrate on making the feature-set complete before going there.
A feature I'd love to have (will use asap) is fast sequential sector read, and I don't mind a more direct programming approach for this, kind of like how it is today. But in the end it would be nice to have generic streaming support and sector read/write via proper API-vectors.
I'll have a more thorough think about this and be back.