[Coco] Frank Hogg Labs E-Forth, patched to run on the CoCo3FPGA + VCC + Jeff Vavasour's emulator

[Stephen Pereira]

Hi Leslie,

> When you first start up the program, try typing:
> 
> cr .( test)
> 
> Do you get "test ok" , or "cr ?" as a result?

On the CoCo3FPGA, if I type that sequence right after startup, I get the line: test ok

But please remember that I said that the system did not complain about using cr in a direct entry.

> What *exactly* happens on CoCo3FPGA when you try loading block#1 ?


As I said before, when I type the command: 1 load

The system comes back with: cr ?

I believe this is the cr at the beginning of line 0 on screen 1.  My belief is that something to do with Drivewire is fouling up the load, and possibly E-Forth is confused and issues that error.

> I'm not sure there is any need to load block#1 ?


I understand what you say.  When I type: origin

The system comes back with: origin ?

Since origin is one of the system memory boundaries, this error concerns me.  However, I agree with you that so many duplicate dictionary entries probably means that all those commands are already loaded, but I was thinking maybe they have to be loaded again - nah, that’s not right.

And, again, when I go ahead and type: 3 load

The system comes back with: ( ?

I believe this is the ( at the beginning of line 0 on screen 3.  This strengthens my concern that we are dealing with something to do with Drivewire on the CoCo3FPGA.

We may not be able to do anything about E-Forth not wanting to deal with Drivewire.  And, not having Drivewire on the CoCo3FPGA will mean that one cannot save any of the new code that may be entered, effectively neutering the system for any real use.

Thanks!

smp
- - -
Stephen Pereira
Bedford, NH  03110
KB1SXE


> On Feb 25, 2018, at 1:39 AM, Leslie Ayling <layling at bigpond.net.au> wrote:
> 
> Hi Stephen,
> 
> When you first start up the program, try typing:
> 
> cr .( test)
> 
> Do you get "test ok" , or "cr ?" as a result?
> 
> What do you get on a real coco with CoCoSDC vs. CoCoFPGA?
> 
> If you LOADM"EFORTH.BIN
> Then eject the disk.
> Then "EXEC"
> 
> The cr word should already be visible without the disk being there. 
> 
> ----
> 
> If I try "1 load" on VCC 2.01, it responds with a load of "xxxx isn't unique" errors followed by "branch too long".
> 
> What *exactly* happens on CoCo3FPGA when you try loading block#1 ?
> 
> ----
> 
> I'm not sure there is any need to load block#1 ?
> 
> Looks as though the extra words in block #1 have already been loaded in on the disk
> that came from the coco archive.
> 
> Cheers,
> Leslie
> 
> 
> -----Original Message-----
> From: Coco [mailto:coco-bounces at maltedmedia.com] On Behalf Of Stephen Pereira
> Sent: Sunday, 25 February 2018 1:17 PM
> To: CoCoList for Color Computer Enthusiasts
> Subject: Re: [Coco] Frank Hogg Labs E-Forth, patched to run on the CoCo3FPGA + VCC + Jeff Vavasour's emulator
> 
> Hi Leslie,
> 
> I got a failure right away when I performed:  1 load
> 
> The system came back with:  cr ?
> 
> Saying that it does not recognize the word cr even though it is defined and works fine in direct entry.
> 
> Screen 1 is the so-called load screen because it asks for all the rest of the screens to be loaded.  I then tried to load screen 2 (I think) directly with:  2 load
> 
> The system came back with: origin ?
> 
> The interesting thing with this one is that even when I tried direct entry of the command origin, the system still emits the error message.  I thought that the origin command is part of the base dictionary, as it is with other instances of Forth.
> 
> That’s the specifics that I can recall.  If you want me to do any experiments, just let me know what.
> 
> Thanks!
> 
> smp
> - - -
> Stephen Pereira
> Bedford, NH. 03110
> KB1SXE