[Forth] New TurboForth video on Youtube

[JonnyBritish]

A final release hopefully is not too far away :-)

 

[lucien2]

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 ?

[Willsy]

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

[Willsy]

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 ) 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

[lucien2]

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).

[unhuman]

Think your PEB needs a new fan

[marc.hull]

 

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 ) 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...

[Willsy]

Sure! I was planning on writing a paper on level 3 disk io in assembly, to remind myself more than anything!

 

I'll get to it. Eventually!