Jump to content
IGNORED

[Forth] New TurboForth video on Youtube


JonnyBritish

Recommended Posts

Great news!

 

I'm currently using Weiand's fig-Forth : Fig-Forth, without documentation. There are 3 words that I don't know how to use: OLD, SAVE and PGM. I think they are used to save/load the compiled dictionnary (like Wycove's SAVE-SYSTEM). Is it possible to do this with TurboForth ?

 

Hi Lucien, not at the moment - I'm getting very low on memory. I'll look at how easy it is to do though.

 

Having said that, TF compiles source from blocks quite quickly anyway ;-)

There are also methods provided (the word DATA) that allows storage in memory of data in a much more efficient way than other Forth systems.

 

Finally, it is possible to load data from blocks (or from disk files if you want) store the data in VDP, and FORGET the code that put it there, meaning the code space can be re-used.

 

Mark

Link to comment
Share on other sites

Great news!

 

I'm currently using Weiand's fig-Forth : Fig-Forth, without documentation. There are 3 words that I don't know how to use: OLD, SAVE and PGM. I think they are used to save/load the compiled dictionnary (like Wycove's SAVE-SYSTEM). Is it possible to do this with TurboForth ?

 

Looking at the issue in more detail, for very boring reasons (mostly, the layout of VDP ram in TF) it would be simpler (for me :roll: ) to provide a similar facility but *not* using PROGRAM format files. Shouldn't be an issue, as the files produced, whatever their format, could only be used in TF anyway.

 

Producing PROGRAM format files is very very easy - it's just a DSR call, however, there are restrictions:

 

LOAD and SAVE (Disk DSR level 3 commands, op-codes 5 & 6) only work from VDP RAM

They can only produce files of 8K or less in size - anything more requires multiple files with an ascending final character in the filename so that they can be easily re-loaded later.

 

Now, it would be quite simple for me to implement, say MSAVE (memory save) where you specify a start address, and a length, and have it transfer the CPU memory in blocks to VDP and save it out to disk - but your VDP memory would be totally trashed afterwards - you'd need to reboot your machine with BYE.

 

However, *if* I implemented the using IF128 files, you could save the entire 24K as one single file, and the only VDP requirement would be 128 bytes, which is already allocated as a work buffer anyway.

 

So, to save the 24K memory to disk, you would do:

MSAVE A000$ 6000$ DSK1.DUMPH

And to save low memory:

MSAVE 2300$ 1D00$ DSK1.DUMPL

 

I'll have a look at the memory requirements. If I can make it fit on top of the functionality I still want to add, I'll add it. It would be a neat feature :)

Link to comment
Share on other sites

Hi, thanks for the reply.

 

TF compiles source from blocks quite quickly anyway ;-)

Good to know :) , that's actually my problem with fig-Forth. I must always switch classic99 overdrive ON and OFF.

 

MSAVE A000$ 6000$ DSK1.DUMPH

Thanks, that helped me to understand the SAVE and OLD words from fig-Forth.

You must simply type "SAVE DSK1.XXX" and "OLD DSK1.XXX" and it saves/loads the dictionnary almost instantly (only the user-defined words).

Link to comment
Share on other sites

 

Looking at the issue in more detail, for very boring reasons (mostly, the layout of VDP ram in TF) it would be simpler (for me :roll: ) to provide a similar facility but *not* using PROGRAM format files. Shouldn't be an issue, as the files produced, whatever their format, could only be used in TF anyway.

 

Producing PROGRAM format files is very very easy - it's just a DSR call, however, there are restrictions:

 

LOAD and SAVE (Disk DSR level 3 commands, op-codes 5 & 6) only work from VDP RAM

They can only produce files of 8K or less in size - anything more requires multiple files with an ascending final character in the filename so that they can be easily re-loaded later.

 

Now, it would be quite simple for me to implement, say MSAVE (memory save) where you specify a start address, and a length, and have it transfer the CPU memory in blocks to VDP and save it out to disk - but your VDP memory would be totally trashed afterwards - you'd need to reboot your machine with BYE.

 

However, *if* I implemented the using IF128 files, you could save the entire 24K as one single file, and the only VDP requirement would be 128 bytes, which is already allocated as a work buffer anyway.

 

So, to save the 24K memory to disk, you would do:

MSAVE A000$ 6000$ DSK1.DUMPH

And to save low memory:

MSAVE 2300$ 1D00$ DSK1.DUMPL

 

I'll have a look at the memory requirements. If I can make it fit on top of the functionality I still want to add, I'll add it. It would be a neat feature :)

 

 

Mark...

 

Sorry to hijack, I'll be brief. You seem to have your head wrapped around this file I/o in assembly. How about a layman's tutorial for the rest of use. Kind of an I/O for dummies ;-).

 

Marc...

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...