MicroPicoDrive Popopo's version

[Popopo]

great, compatibility is an excellent feature.

Completely agree with you.

Is the Bluetooth, updating the cartridge or can the QL access the Bluetooth interface?

Good questions,
... very good questions. Everything will be possible.
Everything... but... considering my time and my actual acknowledge level, my first approach will be only to transfer directly from a computer/phone/tablet (whatever that can run Java and has bluetooth connection) the images to the MDP.

Second stage: bi-directionality. I mean... be able to save changes. I understand the most part of us, just want to load things and most part of time we don't make changes on the Microdrives images. For example to load a game, to test our software directly from the emulator to the real QL, and so on... so that matter (persistence in hardware PC hard disk, whatever) will come in this stage.

Third Stage: Last one from my side... allows the QL from its OS to do it directly from commands. For that I need to study how QL does it with other solutions. Already I know by commands or aiming at a number MDV reader that doesn't exist (or something like that). But that, requires a better acknowledge from my side that I consider that now I am not close from it (could takes me in the best case about 4 months).

Keep in mind, that everyone with a better level than me (and more skilled) can developed it easily already at any time. But I am not so skilled and need time that I must take from personal one.

I think, by now what we are getting is not a bad solution at all. (thanks to the many users and people giving me very constructive feed back and info).

[Peter]

... very good questions. Everything will be possible.

I admire your enthusiasm

[Popopo]

I admire your enthusiasm

Thanks
Such a pity you don't like more the results & vision
I like your acknowledge and I admire your work.

[Popopo]

Hi all!

I factoring the code in order to add new features "soon" and found the source of the problem, it seems to me (with my tests) that the problem is solved.
At least I couldn't reproduce any more the problem.

Here is the RC11.
If it appears again (I hope not) under any configuration, please to report it indicating the file structure of the dir.
This time it happened when the root directory ended had in the last entry of its table aiming a file. When it was a directory the problem didn't appear.
Now in my computer it doesn't hang any more.

RPD RC11.zip

(39.74 KiB) Downloaded 180 times

[Popopo]

Good Afternoon folks!

After talking and getting information about the matter that we talked about recently here, Johan Engdhal has shared its tools for the Magic Field.
So I think it is a very useful tool, even when Dr Gusman has his tool, this one is also a very nice one and I love diversity creativity. So everyone can use what likes the most.

A while ago I shared the a Linux binary that I created to create or reinstate the MagicHeader of a QL binary (it will create the correct header for a QL binary compiled with C68 or XTC68. It will set the magic file header in such way that header is inserted and can thus be run directly on a QL without the SEXEC process).
Upon request I have now compiled it for Win x64 architecture as well. Please note that this is a command line tool.

Thanks Johan!

Here is the tool. Enjoy it.

QDOSMagicHeaderFixer.zip

(5 MiB) Downloaded 195 times

[dilwyn]

There's an article on my blog about the "magic headers" (XTcc fields) and how it works, and how to check it. Also some suggestions on restoring lost executable file headers by guesswork where no XTcc field exists.

Some people use the term "magic field" to refer to the original executable file header, while others use it to refer to the "XTcc" fields within a program if it exists, so the term can be ambiguous.

An XTcc field is essentially a little bit of flagged data (a long word) inserted into an executable program file by compilers to indicate what dataspace the executable should have when put into a QL filing system. It's usually used by cross-compilers (programs which compile QL programs in non-QL environments such as Windows or DOS, e.g. XTC68). You can locate it within a program (if it exists) just by searching for the letters "XTcc" which precedes the long word.

Once upon a time, it was little known or understood. Nowadays, more software understands the XTcc field.

Really useful to know about if you are transferring between filing systems and accidentally lose the executable file header.

EDIT: forgot to include the link to the blog article: https://dilwyn2.wordpress.com/2017/02/2 ... e-headers/

[Popopo]

There's an article on my blog about the "magic headers" (XTcc fields) and how it works, and how to check it. Also some suggestions on restoring lost executable file headers by guesswork where no XTcc field exists.

Some people use the term "magic field" to refer to the original executable file header, while others use it to refer to the "XTcc" fields within a program if it exists, so the term can be ambiguous.

An XTcc field is essentially a little bit of flagged data (a long word) inserted into an executable program file by compilers to indicate what dataspace the executable should have when put into a QL filing system. It's usually used by cross-compilers (programs which compile QL programs in non-QL environments such as Windows or DOS, e.g. XTC68). You can locate it within a program (if it exists) just by searching for the letters "XTcc" which precedes the long word.

Once upon a time, it was little known or understood. Nowadays, more software understands the XTcc field.

Really useful to know about if you are transferring between filing systems and accidentally lose the executable file header.

EDIT: forgot to include the link to the blog article: https://dilwyn2.wordpress.com/2017/02/2 ... e-headers/

Thank you very much dilwyin for that excellent explanation.
I forgot about the link to post it too Johan gave it to me so personally I read it already, and that is a very excellent document to understand the matter.
Will be very useful for people like me that are new in this QL World. So, let me share it alongside with the post that I have published in the Software section.
(and your explanation here).

[Derek_Stewart]

Good Afternoon folks!

After talking and getting information about the matter that we talked about recently here, Johan Engdhal has shared its tools for the Magic Field.
So I think it is a very useful tool, even when Dr Gusman has his tool, this one is also a very nice one and I love diversity creativity. So everyone can use what likes the most.

A while ago I shared the a Linux binary that I created to create or reinstate the MagicHeader of a QL binary (it will create the correct header for a QL binary compiled with C68 or XTC68. It will set the magic file header in such way that header is inserted and can thus be run directly on a QL without the SEXEC process).
Upon request I have now compiled it for Win x64 architecture as well. Please note that this is a command line tool.

Thanks Johan!

Here is the tool. Enjoy it.
QDOSMagicHeaderFixer.zip

No source code?

But I do not bother this issue, as I never extract an compressed archive like into a non-QDOS environment, so the QDOS executable header is always retained.

[Popopo]

No source code?

But I do not bother this issue, as I never extract an compressed archive like into a non-QDOS environment, so the QDOS executable header is always retained.

I didn't thought about the source code. It is not my soft, so I cannot decide.
Perhaps Johan already shared it time ago.
You have not troubles that is good, other users have it. That is why I started to know the issue.
Since I use Linux, it was not a problem for me neither. Once I got first questions about why didn't work the MDVs in some QLs I started to ask and get information. Then... well, the rest is known in this thread

[Popopo]

Good evening,

Thanks to the report of a user (Jean M Q), a bug have been found in RC11.
The bug consist when trying to save datas in a MDV image. It occasionally report bad media error, trying to saving datas or loading again the image.

The temporal fix is to downgrade it to original version 1.0. (other RC could work too)
During this week I will publish a bugfix, after some other pending tasks.

My apologies for inconvenience.

Here is the scroll to reproduce the issue:

Code: Select all

- power on 
- select chess cartridge [M button] to select, [R button] to load
- [F2]
- load chess => OK
- play chess => OK
- RESET
- deselect chess cartridge [L button]
- [F2]
- select chess cartridge [M button] to select, [R button] to load
- dir mdv1_
- copy BOOT to BOOT_SAV
- delete BOOT
- dir mdv1_
- ed 
- type a little basic program [Esc]
- cls
- run
- save mdv1_demo_bas
- dir
- new
- list 
- load mdv1_demo_bas
- run
- save chess cartridge [R button]
- power off
- wait 6s
- power on
- select chess cartridge [M button] to select, [R button] to load

- [F2]
- dir mdv1_
- load demo_bas
- run
- dir mdv1_
- lrun BOOT_SAV => bad or changed medium
- reset
- dir mdv1_
- load demo_bas
- run 
- load BOOT_SAV
- list
- dir mdv1_
- EW mdv1_chess => bad or changed medium

Also this proceed will help me in the future for testing new releases.
Thanks JM.