What's puzzling is that I should need to this at all.

Ok so I found out the same can be achieved using WIPE.

1 EDIT WIPE

will initialize the buffer after which the LOADS command can be used to retrieve the screen from the file without the
junk & error message.
Reading the manual I was reminded ...

An ascii text OCR of the manual will be available shortly. I need to clean up a few errors.
It's now ready. I omitted scans of the fig-Forth manual included in the PDF (not sure it was
originally provided and can be obtained separately in any case).

http://s000.tinyupload.com/index.php?file_id ...

An ascii text OCR of the manual will be available shortly. I need to clean up a few errors.

Ok so I found out the same can be achieved using WIPE.

1 EDIT WIPE

will initialize the buffer after which the LOADS command can be used to retrieve the screen from the file without the
junk & error message.

I encountered an issue that puzzling. After loading a screen previously saved to a file (cassette or disk) it would be followed
by a string of junk graphic characters and an error msg. I managed to avoid the spurious junk and error msg by executing
the following after booting up HES VICFORTH:

FIRST ...

WinRAR in ZIP mode. D/loaded & it extracted ok with WinRAR and Win10 explorer.

A zip containing HES VICFORTH dump, manual scan and disassembly is here:

http://s000.tinyupload.com/index.php?fi ... 1945757767

Thanks to everyone involved!

Thanks Nyef.

As Datatronic VICFORTH was mentioned below is a link to that one. I've updated the zip with a new version of the MS-DOS screen editor (old one didn't work under DOSBOX for some reason). Also included is a disassembly. There appears to be some free space in the ROM image potentially ...

Anyway, aside from arranging for bdk6 to obtain a copy of the final file, is there anything else that I should be doing with it?
The HES VIC FORTH cartridge is on the 'rare list' and unavailable even as a binary dump for use with VIC emulators. I'm sure Forth fans and Commodore sites would welcome ...

I knew of a U/ bug in 6502 fig-forth (it was well publicized) but never heard of issues with U*. This prompted some digging. There's a discrepancy in the U* code published in the Fig Installation Manual (Nov 1980) and what's contained in Fig 6502 Rel 1.1 asm listing (Sep 1980) from http://www.forth ...

... particularly when there is D< to handle the exceptional cases. But that was Garth's original beef. D< DIDN'T handle the exceptional cases for him, and he had to re-write the primitive. I can only go by comments made here which suggests the 'bug fix' was driven by expectations rather than ...

To me, it's not a matter of modern vs. vintage, but more of a matter of correct vs. incorrect. ... In the case of Forth, I believe that access to the overflow flag was limited for application programs, so that duty should have fallen on the person writing the primitives. In Borland Pascal I can ...

I'm a bit fuzzy this morning (haven't gone to the gym yet), but a simple-minded search of the document yields no "discussion" of D< ... just a brief one-line definition. See section 2.2.2
Any way you look at it, for D< to say that -70007FFF was not less than 0FFF8002 in signed 32-bit numbers is ...

In the Forth 83 topic, I mentioned a bug in D< that I think is in the in the public-domain material (but if not, it's certainly nothing to defend if it is wrong !), but apparently I never discussed it... Most early Forths defined '<' and 'D<' in the same manner. It wasn't a bug but a "feature ...