acknowledged, just got the one posted 6 min ago now
MJB can see your evil waste in the kernel now, beware
ok ok - I am the 'big brother watching for wasted bytes now' ;-)
AND you see my good intention ??
I had a little bit the impression focus was shifted to P2-Tachyon now,
so I am happy to see P1-Tachyon is still very alife and growing.
Most of my projects will continue to be P1 for a long time.
let's continue the fun
and don't forget - 'I am your friend' - not a C-proposing Forth critic ;-)
acknowledged, just got the one posted 6 min ago now
MJB can see your evil waste in the kernel now, beware
ok ok - I am the 'big brother watching for wasted bytes now' ;-)
AND you see my good intention ??
I had a little bit the impression focus was shifted to P2-Tachyon now,
so I am happy to see P1-Tachyon is still very alife and growing.
Most of my projects will continue to be P1 for a long time.
let's continue the fun
and don't forget - 'I am your friend' - not a C-proposing Forth critic ;-)
Ok, you are officially the WME (waste management expert), to keep a look out for bits and bytes wasted (as a friend of course).
==============> WORM (Waste Of Resources Manager)
Many may be caught up in P2 fantasy land but I have an immediate need for P2 which although only available in expensive FPGA at present I can just manage to get away with this for some prototypes. I will be in big trouble if it is delayed but I also have prepared my alternative which might include a network of P1s or perhaps an ARM and a P1.
So the only REAL chip for the REAL world besides fantasies is the P1 and so it's a matter of making these do what I need and perhaps I may be asking more of them in the near future which is why I need those ROMs and reliable multi-chip networking. I could have done this years ago but P2 was always just around the corner.......... :depressed:
btw, mind your "language", we will have none of that "C" word around here
V3 includes LMM interpreter - adding support to assembler
Another nice little feature I have built into Tachyon with some cog memory I saved was a simple LMM loop which with the support of the interactive assembler allows LMM to be written inline and mixed with Tachyon code. LMM can even jmp to Tachyon opcodes in the cog and return back to the LMM loop if the "unext" pointer is changed from Tachyon's interpreter loop to LMM's. A simple restore is all that is needed to fix it back up again. Since it uses Tachyon's IP instruction pointer for its PC it means that after a return it can continue executing Tachyon bytecode immediately after the LMM. Well, we will have to see how it works out in practice but it is a convenient way to include some LMM PASM inline or even just LMM code definitions.
btw: "code <name>" creates a regular Forth dictionary header but the first code byte is the opcode for the LMM interpreter with the code long aligned of course.
The assembler uses regular syntax with some subtle modifications. Here's a little sample of what it looks like at present and in interactive mode it indents for the source and spits out the assembled code on the left as you go.
code STREND ( ptr -- ptr2 )
fchlp rdbyte R0,tos ( read a byte )
sub R0, # 1 ( end is either a null or anything >$7F )
cmp R0, # $7E wc
if_c add tos, # 1
if_c mov IP, # fchlp
jmp unext
endcode
EDIT: Actually, I could easily add an LMM style jmp in place of "mov IP", I don't know if there is one used already but I could just say "jmpl #fchlp"
Seems I'm missing something in usage of this ROM. I believe F32 is usually started in a cog, in Tachyon we do this:
3 " F32 " LOADCOG
And I thought from the assembler this should leave F32 running in the cog waiting for a :execCmd but I don't see it running in lscogs?
So my question is how to use this in Tachyon, one simple example would help here. I do realize I need to pass appropriate params to the LOADCOG i.e. result, fa, fb but the syntax is escaping me here.
Then test it with a simple float add which in Spin is:
PUB FAdd(a, b)
result := cmdFAdd
f32_Cmd := @result
repeat
while f32_Cmd
But f32cmd looks like it is actually an address pointing to [result,fNumA,fNumB] which you could create with "3 longs result" where result is the command and the result.
So setup the 3 longs first "cmdF+ result !" before pointing F32cmd to it like this "result f32cmd !"
When f32cmd is set to zero then you can read the result.
However I'm really tired so I'm not reading this well at the moment. I will get my head into it tomorrow.
Actually, here's some quick test code to get you going:
( define some variables and constants )
long f32cmd
3 longs result
result 4 + == fnumA
fnumA 4 + == fnumB
f32cmd 3 " F32 " LOADCOG ( start up F32 )
: FCMD ( n1 n2 cmd -- result ) result ! fnumB ! fnumA ! result f32cmd ! begin f32cmd @ 0= until result @ ;
: >F ( n1 -- result ) 0 $5CFC8E42 FCMD ;
: F> ( n1 -- result ) 1 $5CFCBE48 FCMD ;
: F+ ( n1 n2 -- result ) $5CFC3C0D FCMD ;
: F- ( n1 n2 -- result ) $5CFC3C0C FCMD ;
: F* ( n1 n2 -- result ) $5CFC641F FCMD ;
: F/ ( n1 n2 -- result ) $5CFC6233 FCMD ;
: FSIN ( n1 -- result ) 0 $5CFD72A2 FCMD ;
: FSQR ( n1 -- result ) 0 $5CFD006C FCMD ;
( test out a simple F+ 4095.761 + 4095.761 )
$457FFC2E DUP F+ .LONG
$457FFC2E DUP F+ $457FFC2E F- .LONG
$BAC90FDC FSIN .LONG
$457FFC2E DUP F* .LONG
$457FFC2E DUP F* FSQR .LONG
987 DUP * >F FSQR F> .[s][/s]
Look in the Tachyon extras folder for a file called "F32 tests.fth"
12345 DUP * . 152399025 ok
12345 DUP * LAP >F LAP .LAP 37.200us ok
LAP FSQR LAP .LAP 52.200us ok
LAP F> LAP .LAP 37.400us ok
. 12345 ok
Wow, haven't been able to follow for a few days and a new Tachyon is born.
Happy birthday TF3; ) congratulations
Still "TF1" or just plain "TF" as opposed to TF2, the P2 version but in retrospect (if you can call a few days that) I think you and MJB kicked this off. How so? Well I added the extra print functions and MJB got a little upset, as we do from time to time, and as I had been looking at the memory map previously to see where I could consolidate memory, I decided to try a few things.
So I had always wondered whether I would save memory by reducing the size of the XCALL vectors that allow the kernel to call high level bytecode functions using just 2 bytes (XCALL + VECTOR). The vectors are needed to keep the source code simple and clean and still work with the Prop tool or BST but once Forth itself is compiling functions it can compile calls as 16-bits using 3 bytes which is what it does when the XCALL table is filled. When I made the changes and tried them out by compiling EXTEND, hardware headers, SDCARD, and EASYFILE I found I still ended up saving around 400 bytes so it seemed like the thing to do.
But those compiled PASM images for the cogs were hogging a lot more memory than that even if some were reused as generous buffers. The VGA image is not used very often but quite handy and it had a small footprint, but it still takes up some memory, how to get rid of it and still have it but as we know you can't have your cake and eat it too, that's impossible! Well as soon as I told myself it was impossible then it became possible, I would use up memory with PASM images and then allow Forth to reuse that area when it does a backup to EEPROM as a backup normally avoids the PASM image for the kernel and console receive of course. So all I had to do was add some means for a Forth routine to scan for them in EEPROM (that part of RAM gets overwritten by EXTEND itself) and then save them in upper EEPROM - before a BACKUP. Then add some extra functions to find individual images by name and be able to launch them.
So now we have V3.0 JUNO with a library of ROMs and floating point etc, and it all started with you and MJB, and then D.P "nagging" me about FP
BTW, floating point really needs some way to enter and print fp numbers, so I will look into this soon. I also forgot that I had added LMM and methods too.
when doing this major revision,
maybe you can change ACC to spicnt in SPIWR16,
so it is consistent with the documentation and SPIWRX can be used as described,
by loading 'n spicnt COGREG! ' before, which is very hard with ACC as it is now.
@Peter ... may I bring up this little thing again ...
will not load ADC module, even if specified with LOADMODs, when NOT in EXPLORER mode.
Maybe
IFDEF EXPLORER
: INCLUDE $FFFFFFFF ; --- include all for EXPLORER
}
or a specific list, would be a better option than the mix of MODULE and IF(N)DEF EXPLORER / SMALL ... like
The a bit more verbous MODULE loader I started quite some time ago would take care of module dependencies, so if 17 has a prerequisite of 5 and 5 needs 3 then just specifying 17 would pull in all in the right sequence (i.e. as defined in EXTEND).
Extend was just to much changing all the time to get a stable dependency matrix.
This is not critical now, that we have sooo much more space.
But Tachyon and applications will continue to grow.
Good to know we can come back to this when space is getting full again.
@MJB - I have been using an alternate EXTEND which checks for IFDEF EXPLORER rather than a IFNDEF SMALL etc. Seems to be a lot better as I am trying to get away from specifying includes but EXPLORER could be set to include all.
@MJB - I have been using an alternate EXTEND which checks for IFDEF EXPLORER rather than a IFNDEF SMALL etc. Seems to be a lot better as I am trying to get away from specifying includes but EXPLORER could be set to include all.
Those other minor things I can certainly fix.
I was referring to yesterdays EXTEND.fth version ...
Peter,
Time to get my feet wet
So some questions first.
Can I just use Tachyon with an SD Card? As you probably know I have a Propeller OS that runs on SD Card. It uses FAT32 (also supports FAT16) and the EEPROM is loaded to boot into the OS on the SD Card. From there, using a terminal on P30/31 I can load any propeller binary file. So...
* Can I load Tachyon V3 from the SD Card?
* Does Tachyon require (any of) the lower 32KB of the EEROM? (upper 32KB is fine)
Tachyon is designed to work with a minimal system comprised of a Prop, a crystal, and a 32kB EEPROM although 64kB is more common and preferred. But the kernel that is compiled with the Propeller tool doesn't even know about EEPROM itself, so you could just load it into RAM but EXTEND.fth which is compiled by the Tachyon kernel itself has EEPROM utilities onboard so it can backup to EEPROM etc. Other modules that can be loaded include the SDCARD and EASYFILE FAT32 extensions.
If you want a loader shell to load Tachyon then isn't that the same as any other binary? But if you want to build your own binary from the kernel as mentioned you need to be able to save it on the SD card which you can do with Tachyon itself. Once Tachyon knows how to access the SD card you can load source code into Tachyon from files directly.
So to get started I would load in Tachyon into RAM then load in EXTEND.fth BUT just comment out the BACKUP at the end of the source if you don't want it overwriting your O/S. Before you do much more you may want to disable BACKUP by creating a dummy backup with : BACKUP ;
Then create a hardware header file in the manner of QS.H etc that specify your SD pin assignments for instance after which you can load SDCARD and EASYFILE after which you can save your binary to the card although at present you need to create a dummy 64K file called FIRMWARE.ROM so that you can type SAVEROM instead of BACKUP to save the kernel image to the card. Of course you can use Tachyon to rename this file etc or whatever.
Peter, Where is V3.0 located (source as I will need to recompile since I currently am using a 12MHz xtal)?
Found on your dropbox link. BTW your "Intro + links" links to V2.3.
I can find v2.3 but not 3.0. I have (and use) bst.
TACHYON
[~
FORGET PX2.fth
pub PX2.fth ." P8XBlade2 HARDWARE DEFINITIONS 160724.0000 " ;
--- Cluso's P8XBlade2 ---
( P8X32A PINOUTS )
#P15 |< == &SDCS '' SDCARD CS
#P14 |< == &SDDI '' Data to SDCARD
#P13 |< == &SDCK '' SDCARD clocks
#P12 |< == &SDDO '' Data out from SDCARD
&SDCS >| #24 SHL &SDDO >| 16 SHL OR &SDDI >| 8 SHL OR &SDCK >| OR == SDC
( PCB DEFINITIONS )
\ Do what we need to do to init the hardware on this pcb
pub !PCB
&SDCS OUTSET
;
" P8XBlade2" 0 STRING PCB$
#8888 == PCB
]~
END
I have downloaded the latest Tachyon V3.0 Juno from DropBox and after changing the xtal freq, compiled with bst and downloaded to my pcb. Get the Tachyon message OK.
All good so far
I tried adding EXTEND.FTH but I get this error
Tachyon V3.0 and Extend.fth both from dropbox (not the zipped file)
----------------------------------------------------------------
Propeller .:.:--TACHYON--:.:. Forth V3.0 JUNO 300160720.0000
Cold start - no user code - setting defaults
----------------------------------------------------------------
ok
( general set of includes when building an expanded TF with filesystem. ) ok
: INCLUDE
\
\
\
\
\
%00_0000101001_1110010100_1101100000
; ok
CREATE SMALL ok
} ok
TACHYON Propeller .:.:--TACHYON--:.:. Forth V3.0 JUNO 300160720.0000
ok
0000 oktest V2.8 kernel or greater )
0001 ok
0002 ok
0003 ok
0004 ok
0005 ok
0006 okTEND.fth
.....
.....
0080 ok
0081 ok
0082 ok
0083 ok
0139 error in CREATE$ at WORD 1- C! word SWAP CMOVE (CREATE) *error*
----------------------------------------------------------------
Presume I need to do something like "CREATE EXPLORER" but not sure how/where???
That early in the load may simply be the fact that you need to set a line delay of around 20ms if you use TeraTerm as there isn't any effective handshake with serial ports these days (things are worse because of deep FIFOs).
Still the same error. I tried editing the EXTEND.FTH file and changing CREATE SMALL to CREATE EXPLORER but that did not work either. Tried using a line delay of 100ms without success. Any ideas???
My bad, I had been changing upper/lower case conflicts with some words in V3 as early on I had identical upper and lower case words and quite some time ago I allowed lower case to be used in searches so that if it failed to find a word it would then promote the searched term to upper case and try again, in which "case" it would succeed. But "word" is the variable for the word buffer whereas WORD is the declaration for a word variable, so I am in the process of changing some small things but I must have been interrupted at the time and I've been away from testing all weekend.
Now, back into the saddle, tested out EXTEND and it is fine now.
I just rebuilt the world without error from current dropbox?
2390 ok---
2391
00:00:00 End of source code, 2392 lines processed and 0000 errors found
Load time = 0.000us
MODULES LOADED:
1787: EXTEND.fth Primary extensions to TACHYON kernel - 160720-1500
VER: Propeller .:.:--TACHYON--:.:. Forth V3.0 JUNO 300160720.0000
FREQ: 80MHZ (PLLEN OSCEN XTAL1 PLL16X)
NAMES: $5B62...74C6 for 6,500 bytes (+3,861)
CODE: $0930...341B for 10,987 bytes (+7,316)
RAM: 10,055 bytes free
BUILD: FIRMWARE BUILD DATE 000000:000000 BOOTS: 0 runtime 0
BOOT: EXTEND.boot ok
ok
IFDEF V3 ok
--- ok
: SAVEROMS
" ROMS" U@ @NAMES 3 ANDN ' TACHYON 3 ANDN
DO I E@ OVER = IF CR PRINT" COPY ROMS @" I .WORD PRINT" for " I 4 + E
4 +LOOP
DROP
; ok
SAVEROMS
COPY ROMS @1738 for 6872 ok
FORGET SAVEROMS ok
} ok
ok
?BACKUP ok
ok
Comments
AND you see my good intention ??
I had a little bit the impression focus was shifted to P2-Tachyon now,
so I am happy to see P1-Tachyon is still very alife and growing.
Most of my projects will continue to be P1 for a long time.
let's continue the fun
and don't forget - 'I am your friend' - not a C-proposing Forth critic ;-)
Sorry, it's a wip and at present I am just searching on a fixed length 8 characters so " F32 " will find it.
Ok, you are officially the WME (waste management expert), to keep a look out for bits and bytes wasted
==============> WORM (Waste Of Resources Manager)
Many may be caught up in P2 fantasy land but I have an immediate need for P2 which although only available in expensive FPGA at present I can just manage to get away with this for some prototypes. I will be in big trouble if it is delayed but I also have prepared my alternative which might include a network of P1s or perhaps an ARM and a P1.
So the only REAL chip for the REAL world besides fantasies is the P1 and so it's a matter of making these do what I need and perhaps I may be asking more of them in the near future which is why I need those ROMs and reliable multi-chip networking. I could have done this years ago but P2 was always just around the corner.......... :depressed:
btw, mind your "language", we will have none of that "C" word around here
languages.
Leo Brodie, Thinking Forth
Yeah regarding the F32, just got there in the source.
Another nice little feature I have built into Tachyon with some cog memory I saved was a simple LMM loop which with the support of the interactive assembler allows LMM to be written inline and mixed with Tachyon code. LMM can even jmp to Tachyon opcodes in the cog and return back to the LMM loop if the "unext" pointer is changed from Tachyon's interpreter loop to LMM's. A simple restore is all that is needed to fix it back up again. Since it uses Tachyon's IP instruction pointer for its PC it means that after a return it can continue executing Tachyon bytecode immediately after the LMM. Well, we will have to see how it works out in practice but it is a convenient way to include some LMM PASM inline or even just LMM code definitions.
btw: "code <name>" creates a regular Forth dictionary header but the first code byte is the opcode for the LMM interpreter with the code long aligned of course.
The assembler uses regular syntax with some subtle modifications. Here's a little sample of what it looks like at present and in interactive mode it indents for the source and spits out the assembled code on the left as you go.
code STREND ( ptr -- ptr2 ) fchlp rdbyte R0,tos ( read a byte ) sub R0, # 1 ( end is either a null or anything >$7F ) cmp R0, # $7E wc if_c add tos, # 1 if_c mov IP, # fchlp jmp unext endcodeEDIT: Actually, I could easily add an LMM style jmp in place of "mov IP", I don't know if there is one used already but I could just say "jmpl #fchlp"Seems I'm missing something in usage of this ROM. I believe F32 is usually started in a cog, in Tachyon we do this:
And I thought from the assembler this should leave F32 running in the cog waiting for a :execCmd but I don't see it running in lscogs?
So my question is how to use this in Tachyon, one simple example would help here. I do realize I need to pass appropriate params to the LOADCOG i.e. result, fa, fb but the syntax is escaping me here.
Thanks
The syntax for loading a cog is like this:
So you need to supply the parameter which is a pointer to the F32 command just as Spin does it:
So create a long and pass that like this:
Then test it with a simple float add which in Spin is:
But f32cmd looks like it is actually an address pointing to [result,fNumA,fNumB] which you could create with "3 longs result" where result is the command and the result.
So setup the 3 longs first "cmdF+ result !" before pointing F32cmd to it like this "result f32cmd !"
When f32cmd is set to zero then you can read the result.
However I'm really tired so I'm not reading this well at the moment. I will get my head into it tomorrow.
Actually, here's some quick test code to get you going:
Look in the Tachyon extras folder for a file called "F32 tests.fth"
Okay thanks and goodnight
Happy birthday TF3; ) congratulations
Still "TF1" or just plain "TF" as opposed to TF2, the P2 version but in retrospect (if you can call a few days that) I think you and MJB kicked this off. How so? Well I added the extra print functions and MJB got a little upset, as we do from time to time, and as I had been looking at the memory map previously to see where I could consolidate memory, I decided to try a few things.
So I had always wondered whether I would save memory by reducing the size of the XCALL vectors that allow the kernel to call high level bytecode functions using just 2 bytes (XCALL + VECTOR). The vectors are needed to keep the source code simple and clean and still work with the Prop tool or BST but once Forth itself is compiling functions it can compile calls as 16-bits using 3 bytes which is what it does when the XCALL table is filled. When I made the changes and tried them out by compiling EXTEND, hardware headers, SDCARD, and EASYFILE I found I still ended up saving around 400 bytes so it seemed like the thing to do.
But those compiled PASM images for the cogs were hogging a lot more memory than that even if some were reused as generous buffers. The VGA image is not used very often but quite handy and it had a small footprint, but it still takes up some memory, how to get rid of it and still have it but as we know you can't have your cake and eat it too, that's impossible! Well as soon as I told myself it was impossible then it became possible, I would use up memory with PASM images and then allow Forth to reuse that area when it does a backup to EEPROM as a backup normally avoids the PASM image for the kernel and console receive of course. So all I had to do was add some means for a Forth routine to scan for them in EEPROM (that part of RAM gets overwritten by EXTEND itself) and then save them in upper EEPROM - before a BACKUP. Then add some extra functions to find individual images by name and be able to launch them.
So now we have V3.0 JUNO with a library of ROMs and floating point etc, and it all started with you and MJB, and then D.P "nagging" me about FP
BTW, floating point really needs some way to enter and print fp numbers, so I will look into this soon. I also forgot that I had added LMM and methods too.
I think FCREATE$ was not fully implemented yet ...
e.g. Finding a free DIR entry and writing data there ..
It's been on my to-do list for a while but if you get it working then I'm fine with that too!
- just saw it and wanted to remind you.
EXTEND.fth should be pub ??
will not load ADC module, even if specified with LOADMODs, when NOT in EXPLORER mode.
Maybe
IFDEF EXPLORER : INCLUDE $FFFFFFFF ; --- include all for EXPLORER }or a specific list, would be a better option than the mix of MODULE and IF(N)DEF EXPLORER / SMALL ... likeThe a bit more verbous MODULE loader I started quite some time ago would take care of module dependencies, so if 17 has a prerequisite of 5 and 5 needs 3 then just specifying 17 would pull in all in the right sequence (i.e. as defined in EXTEND).
Extend was just to much changing all the time to get a stable dependency matrix.
This is not critical now, that we have sooo much more space.
But Tachyon and applications will continue to grow.
Good to know we can come back to this when space is getting full again.
Those other minor things I can certainly fix.
I was referring to yesterdays EXTEND.fth version ...
Time to get my feet wet
So some questions first.
Can I just use Tachyon with an SD Card? As you probably know I have a Propeller OS that runs on SD Card. It uses FAT32 (also supports FAT16) and the EEPROM is loaded to boot into the OS on the SD Card. From there, using a terminal on P30/31 I can load any propeller binary file. So...
* Can I load Tachyon V3 from the SD Card?
* Does Tachyon require (any of) the lower 32KB of the EEROM? (upper 32KB is fine)
If you want a loader shell to load Tachyon then isn't that the same as any other binary? But if you want to build your own binary from the kernel as mentioned you need to be able to save it on the SD card which you can do with Tachyon itself. Once Tachyon knows how to access the SD card you can load source code into Tachyon from files directly.
So to get started I would load in Tachyon into RAM then load in EXTEND.fth BUT just comment out the BACKUP at the end of the source if you don't want it overwriting your O/S. Before you do much more you may want to disable BACKUP by creating a dummy backup with : BACKUP ;
Then create a hardware header file in the manner of QS.H etc that specify your SD pin assignments for instance after which you can load SDCARD and EASYFILE after which you can save your binary to the card although at present you need to create a dummy 64K file called FIRMWARE.ROM so that you can type SAVEROM instead of BACKUP to save the kernel image to the card. Of course you can use Tachyon to rename this file etc or whatever.
Where is V3.0 located (source as I will need to recompile since I currently am using a 12MHz xtal)?
Found on your dropbox link. BTW your "Intro + links" links to V2.3.
I can find v2.3 but not 3.0. I have (and use) bst.
TACHYON [~ FORGET PX2.fth pub PX2.fth ." P8XBlade2 HARDWARE DEFINITIONS 160724.0000 " ; --- Cluso's P8XBlade2 --- ( P8X32A PINOUTS ) #P15 |< == &SDCS '' SDCARD CS #P14 |< == &SDDI '' Data to SDCARD #P13 |< == &SDCK '' SDCARD clocks #P12 |< == &SDDO '' Data out from SDCARD &SDCS >| #24 SHL &SDDO >| 16 SHL OR &SDDI >| 8 SHL OR &SDCK >| OR == SDC ( PCB DEFINITIONS ) \ Do what we need to do to init the hardware on this pcb pub !PCB &SDCS OUTSET ; " P8XBlade2" 0 STRING PCB$ #8888 == PCB ]~ ENDI have downloaded the latest Tachyon V3.0 Juno from DropBox and after changing the xtal freq, compiled with bst and downloaded to my pcb. Get the Tachyon message OK.
All good so far
Tachyon V3.0 and Extend.fth both from dropbox (not the zipped file)
Presume I need to do something like "CREATE EXPLORER" but not sure how/where???
Send a break if you want to reset it.
115200 baud
Now, back into the saddle, tested out EXTEND and it is fine now.
2390 ok--- 2391 00:00:00 End of source code, 2392 lines processed and 0000 errors found Load time = 0.000us MODULES LOADED: 1787: EXTEND.fth Primary extensions to TACHYON kernel - 160720-1500 VER: Propeller .:.:--TACHYON--:.:. Forth V3.0 JUNO 300160720.0000 FREQ: 80MHZ (PLLEN OSCEN XTAL1 PLL16X) NAMES: $5B62...74C6 for 6,500 bytes (+3,861) CODE: $0930...341B for 10,987 bytes (+7,316) RAM: 10,055 bytes free BUILD: FIRMWARE BUILD DATE 000000:000000 BOOTS: 0 runtime 0 BOOT: EXTEND.boot ok ok IFDEF V3 ok --- ok : SAVEROMS " ROMS" U@ @NAMES 3 ANDN ' TACHYON 3 ANDN DO I E@ OVER = IF CR PRINT" COPY ROMS @" I .WORD PRINT" for " I 4 + E 4 +LOOP DROP ; ok SAVEROMS COPY ROMS @1738 for 6872 ok FORGET SAVEROMS ok } ok ok ?BACKUP ok ok