News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu
avatar_HAL6128

Tape to Disc copy help needed

Started by HAL6128, 17:40, 31 May 16

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

HAL6128

I have a problem with copying a file from tape to disc. The tape is KUMA FORTH. There are two files on the tape when I do a CAT:

first file = "KFORTH" (Block 1 to 7 - all blocks ok)
second file = "FORTH BLOCK   *" (Block 1 to 16 * - all blocks ok)

I tried different tools like "JL-Copy Utilities" or "Transmat" or "Copy Boss". But all of them can copy only the first file to disc.

How can I copy the second file? The tools above weren't able to read or recognize the second file.
And what is this asterix/star after the second filename about?

Thanks a lot for helping.
...proudly supported Schnapps Demo, Pentomino and NQ-Music-Disc with GFX

GeoffB17

Er, dunno.


If you don't get any answer, I'll have to dig further about this.


Forth, in effect, used it's own proprietary filing system, although most 'modern' variants now use the normal system facilities.   Under the traditional variant, a block was 1k, and basically the block was mapped to literal sectors of the disk.   There was no 'file' as might normally be understood, and no directory.


How would that work on tape?


I've got an Epson HX-20, which uses tape, and the forth I have on that uses tape files, so it is possible.


However, I'd expect that the read/write process will be built into the forth program, once that has been loaded and is running, then that will be able to act on - for example - 1 LOAD - which will access block 1, read in into the block buffer, 'load' whatever is in the block (new definitions or whatever) and then either proceed from there, or if the block has a --> proceed to the next block.   This mechanism could be quite different to the normal process for reading/loading the initial prog.


So, all the processes that you've used to try to read the file (outside of the Forth 'system') may well not recognise the Forth blocks as any sort of file.   Obviously, the data must be a file of some sort,  just not anything like your progs are expecting or can recognise.


Unless anyone can suggest anything better, or you can find a way to read the data as total audio/binary, your best bet would be to load/run the Forth system, use the edit etc commands to load each block and print it.   Or can you load it from tape and then write to disk?


The data in each block will be 1024 bytes of ASCII text, I would expect.


I'll dig some more.   At least I may have some idea of what to look for?


I wonder if my HX-20 system might give some hints as to how the stuff is stored.   The problem there is that if I have .BLKs on a tape, and I do FILES "CAS0:" to list the files, I get all the individual .BLK files listed OK.   Do you get that, maybe you do?   However, if I use a 'normal' file command, say 'OPEN' and try to read the .BLK I don't think it will work (although I've never tried that!!!).   NB - the .BLK file does not have any CR or LF, so it would be 1024 bytes straight, which may well upset any normal file reading buffer??


Is even a tiny bit of this any help??


Best of luck.


Geoff

SRS

No real help for you, but you can download a copy here : CPCRULEZ > APPLICATIONS > PROGRAMMATION > KUMA FORTH

HAL6128

Thank you both for your hints and information!!

First, the link from @SRS provided a DSK with the same result / content. Only one file (the first I mentioned above with the 7 blocks = 13 kB) which works of course. But no second file.

(And actually I didn't started my Kuma Forth via tape. I copied it to disc and then started it, and it works.)

But... the information provided of the website is more interesting. It seems that it matches to what GeoffB17 has written. An excerpt from the CPCRulez website about "Kuma Forth":

"...Another integral feature of the standard is that the language should allow you complete access to, and control of the hardware. Usually this includes the storage device, discs, as a virtual memory system. Tape based Forths often try to avoid this and use Ram as pseudo storage (reverse polish mentality). However, Kuma Forth bravely attempts to exploit the cassette as fax as possible. You can format an entire tape into a series of blank blocks each of which acts as a Forth program 'screen' for keeping your library of routines and data. The disadvantages are that you have to do a lot of rewinding, etc, but if ever a machine could minimise the inconvenience of this it is the all in one 464 (this version will not exploit discs, but a disc based release is also planned)."

So, maybe there's somekind of data or program code stored on the tape after the main application. I will try it or look deeper what is it for when I load Forth from tape. Let me check it. :)
...proudly supported Schnapps Demo, Pentomino and NQ-Music-Disc with GFX

GeoffB17

Since my earlier message, I did a Google search for 'Kuma Forth'.


Nothing specific, but down the bottom of the first page (or is it the top of the next) there's a link to a .PDF of the documentation for the MSX version of Kuma Forth, version 1.1 - this appears to be the same version.


This explains some details of the tape mechanism.


This too refers to the tape being 'formatted', which in effect writes a series of blank .BLK (pages) to the tape.   The default is 16, which ties up with the CAT result.


Each .BLK has a header, comprising SCRN#nnn (but this could be £ instead of # depending on the character set), this indicates the block numbers, suggesting that the max must by 999.   This is followed by the 1024 bytes of text of the screen, and is terminated by a CHK (but it doesn't say if this is 1 or 2 bytes, or how it is calculated.   It is not clear if this data would show to another prog as one or three items.


I'll look further at my HX-20 forth, which may in fact be very similar.   It also is FIG Forth (where FIG refers to 'Forth Interest Group'), which is one of the two main 'standards' of Forth.   I'll have to try to OPEN a Forth .BLK using normal BASIC and see if the file can be read, and what it contains.   Interesting.


I'll look further at the .PDF file (maybe you should download that if you don't have a manual already).   Maybe other hints there.


There may well be some CPC specific commands in the version you have, and MSX things in the MSX version, but both are Z80.   Using the Forth to produce a listing of the definitions (VLIST, or WORDS) should indicate some definitions that are obviously CPC or MSX.


By the way, I have a version of Forth-83 for CP/M already configured for the PCW, but no doubt it could be changed for the CPC.   This uses .BLK files which are normal CP/M files, where one file contains a number of Forth 'Screens'.   No problem to add extra 'words' to cover CPC-specific things.   One of the nice things about Forth is the ease of mixing ASM with existing Forth words.




[size=78%]Geoff[/size]

robcfg

Can you upload the eav file somewhere for us to take a look?

GeoffB17

What's an 'eav' file, not sure if it's something I was referring to.


I've got a copy now of the .PDF I was referring to, so I can attach that.


If you were referring to the F-83 system, I'll need to check that.   I've got it all spread over a few PCW disks, I think there is a complete 'distribution' copy, but it was back in 198? that I was doing that.   More recently, I have seen a F-83 package for the PCW on at least one archive, and when I checked, it was my version!   Fame at last!!!


Geoff

GeoffB17

HAL - please note that the BLOCK file on your original tape may in fact be nothing.   It could be simply the result of the FORMAT command being run within Forth, which would produce 16 empty blocks.   Unless you have reason to think there is something in there, don't bother with it.


A bigger problem could be that the version you have knows ONLY about the tape, and NOT about the disk?   It may well load the prog from disk OK.   But can it read or write from/to the disk?   Kuma were supposed to be doing a disk version as well.


Geoff

robcfg

It's a typing error, I meant a wav file, sorry.

Powered by SMFPacks Menu Editor Mod