21 replies to this topic

[Marco]

Well, while working on the image viewer some days ago I thought of the following: when we want to access data stored in a file we usually (have to) do it this way: allocate a buffer in RAM, open a file and read (a part of) it's content into that buffer. But that's kind of stupid as we have a buffer holding the complete file content already in the Flash memory. Why copy it into RAM (where we have never enough of anyways) via DOS file I/O?

The calc provides a much better way . As the flash is no conventional "disk" but in fact a memory direct addressable by CPU, the only thing we have to do is: switch any Disk (ROM B to K or Flash L to Q) into any bank of the CPUs address space using EMS, examine the file system to find out where the content of a certain file is located and set a pointer on it's starting adress (pointing anywhere into Flash/ROM then). In fact this isn't very hard to do as ROM disk format isn't that complex and it's designed that way that a file's content is always continuous (unlike on a hard disk where it might be fragmented).

Maybe some thought of this already, too? However, I didn't find any LIB on the file sharing providing this, so I made one

http://www.pageofmar.../devafx/DFA.rar, Features:

- no more need to read a file into memory, it's accessible directly from Flash/ROM!
- don't need extra RAM for buffer thus (e.g. holding sprites or images and so on), and RAM limit also doesn't matter for data size
- the LIB does without DOS file I/O, which will decrease a program's size in fact (system/stdio routines not required + dfa implementation very compact with 200 lines only)
- provides also file searching/enumaration

Note: it's not up in the file sharing already, and currently it's Pascal version only. Maybe someone could make a C version of it? .

Btw there are also 2 testing programs included yet: a tiny explorer listing all .EXE (also those from ROM) but can run programs only that don't require all memory, + a demo mapping drives into EMS banks and showing drive/file info and file contents.

[2072]

I already thought about this (I even removed points to a game in the contest because it wasn't reading data directly from flash...).

I didn't made any lib for that.

Orwell rewrote file access routines so we don't have to use the compiler's lib to access the file system: http://www.casiocalc...es#casfiles-1-0

What doc did you use to make this lib? (I don't understand anything to Pascal)

[Marco]

^^ so seems it was a known method already

I used Oliver Coupelon's Programming Guide, there's a really good description of ROM disk format in chapter 10 or so (and also one of EMS and where to find what disk)

[huhn_m]

I could try to convert it to ASM if it helps anyone.
Maybe it could be linked to C files then.

I understand ASM and PASCAL but I'm a noob at C

But I'll only do it if it helps anyone since my time is limited.

[Orwell]

Yeah this is actually not a recent idea... btw dRXE is based on the same idea, but for executable files only

The main question is: how fast does it work?

[Marco]

I could try to convert it to ASM if it helps anyone.
Maybe it could be linked to C files then.

Yeah this was good cause it also could be used for ASM programs then (not C only). But I guess converting the whole library to pure assembler would mean much work?

The main question is: how fast does it work? 

I think the same as in RXE (it shouldn't make a difference whether the data are instruction opcodes (RXE) or operands (direct file access) unlike the CPU had a cache; well, for 80286 however I remember they have something similar called an "instruction prefetch queue", but V30?): accessing data from flash will be around 13% slower than RAM. I tested this for RXE programs already (see here), not yet for direct file access though. (--> if your program gets too slow you still should prefer copying data into RAM to increase speed, but 13% aren't that much)

[dscoshpe]

Speaking of dRXE, I decided to convert Marco's DFA test and it came up with some interesting results...

First, I discovered that ndisasm, which is what I use to disassemble in dRXE, doesn't handle an odd number of alignment nulls so one of the fixes has to be manually adjusted in dRXE.

On DFAtest.exe after 'Examine' browse the fixes list until you see the fix marked as 'E!' which means there's an error. Double-click it to bring the edit dialog and make these adjustments:
Fix code = mov, register = dx, index = 0, length = 3, starts at = 1670, click OK
You'll notice ndisasm disassembled with a leading null....

After I got it converted correctly I ran it in the wing100 emulator and I got about half of the UI, no selection cursor, no menu... Lol

Perhaps this is a failing of the emulator or the conversion but I thought it was worth sharing.

- dscoshpe -

[huhn_m]

i would guess it is the emulator

I'll try converting it to asm
next monday during my computer studys lessons

[dscoshpe]

I finally found my link cable and tried the RXE conversion I made and I got the exxact same result as in the emulator. There may be an issue that needs to be addressed here or at least something that can be worked around.

What is the significance of this screen? Does this mean that drives can't be located, for instance?

- update: i'm ditching the img tag, host seems to have changed policy so a copy and paste is probably in order
http://free.prohosti...ics/dfatest.png

- dscoshpe -

[Marco]

I also tried to convert it with dRXE and made the adjustments you discribed for the entry marked with E! Then I tried it on the emulator and the calc, but got the same result, too It crashed, but I didn't see anything on the calc screen, even not tha half UI, and on emulator screen it got black with white stripes.

Don't know if this could be the reason, but when I looked into the other entries of the fixes list (that above the E! entry), they show "Fix code: OK" but "Register: E!", so seems they also are not converted correctly?

Btw I can't see the screenshot that you posted dscoshpe, it just shows "user posted image"

I also looked for another thing: when combining RXE format with DFA, you must ensure that DFA doesn't map other drives than the one where the rxe file is located on into bank 2 (address 40000..5FFFF), because the rxe program code (usually executed from bank 2) would be violated else. So you can use banks 3,4 and 5 then only (DFA supports banks 2 to 5 which you can access by random). However, this isn't the error, because the testing program doesn't map any drive anyways before you selected this in the user interface (I also looked into the source again to ensure that the lib and the testing program don't map sth until then).

[dscoshpe]

I decided to just display the link to the image, hopefully the host hasn't changed it's policies too much recently.

Also, the thing about the code "OK" being with a register "E!" is pretty much meaningless, the difference being that something "OK" doesn't make use of the RXE interrupt so it doesn't need the extra information, just some tweaking of the addresses in the instruction. Now if the code is something other than "OK" and the register is "E!" then there is a problem!

I'll think about what could be going on, I'd like to see these things play nicely with each other.

- dscoshpe -

[dscoshpe]

Marco sorry to spam your PM lol but your inbox was full so...

here is a beta you can try on your programs if you like, i still havent figured out why dfa wont work...

http://jove.prohosti.....1.54Beta].exe

you probably have to copy/paste the link to work because of how the host works, it doesnt allow linking from other sites

- dscoshpe -

[Marco]

OK thank you

I wrote you a PM (there's some space left now again )

[huhn_m]

I gave you 50 messages extra storage. See it as a reward for the first place in the comp
Hope this helps
btw. there is also a backup tool to make the space wasted less.

[Marco]

That's great thx

[dscoshpe]

Just confirming that RXE and DFA now work together nicely.

dRXE update will be up soon.

- dscoshpe -

[Marco]

finally uploaded DFA to the file sharing

@admins: damn, I forgot to log in - once more
Could anyone delete the post above made by the guest, please?

Andy.Davies: Done

[2072]

You forgot to tell something important in your description: it's only for pascal programmers

[Marco]

Sorry guys Maybe I'll make a C version someday, too, but currently...

One thing I could do at least is making a program that resides in memory and provides DFA routines through interrupts rather like DOS drivers (you could access it from any language then). Wouldn't be a big thing.

[huhn_m]

I promised to convert it to asm but I looked at the sources and they
seemed very complex to me so no porting right now. Maybe when I've got my notebook.

[dscoshpe]

Following up on dRXE.. I put v1.60 on the file sharing.

Plenty of new features, all are listed in the file sharing and discussed in the ReadMe.txt that comes in the package.

- dscoshpe -