R/W in figforth

[powersoft_51]

I have a figforth running. The editor is when loaded running well when I use the original setting:

Code: Select all

SSIZE     = 128          ; sector size in bytes
NBUF      = 8            ; number of buffers desired in RAM
;                             (SSIZE*NBUF >= 1024 bytes)
BMAG      = 1056         ; total buffer magnitude, in bytes
;                              expressed by SSIZE+4*NBUF

When I make a little program and store it in screen 5, and do 5 load it is working fine!

But when I increase the sector site like this:

Code: Select all

SSIZE     = 512          ; sector size in bytes
NBUF      = 4            ; number of buffers desired in RAM
;                             (SSIZE*NBUF >= 1024 bytes)
BMAG      = 2064         ; total buffer magnitude, in bytes
;                              expressed by SSIZE+4*NBUF

The system is crashing when I do the same as above.
The definition of B/SCR is :

Code: Select all

;
;                                       B/SCR
;                                       SCREEN 35 LINE 10
;                                       Blocks per screen
;
L992      .BYTE $85,"B/SC",$D2
          .WORD L984     ; link to B/BUF
BSCR      .WORD DOCON
          .WORD 1024/SSIZE ; blocks to make one screen

Is there a version where it works with a sector of 512 bytes, or can someone help me with this problem.
The reason is that the buffer of my sd card is also 512 bytes.
My SD-Card interface is working with the sector of 128 bytes, but when the sector is 512 bytes the write operations are reduced by a factor 4.

[okwatts]

As I indicated in the B/BUF thread I have code from one of Bill Shen's (Plasmo) CRC65 boards. I have zipped up the forth asm and listing as well as my modifications for the monitor that applies for my actual read and write routines used by Fig-forth. His board uses a CF card but the sector size is 512 bytes as in the SD card. I used essentially the same code for Grant Searles Multicomp with the SD card. Hope this helps.

[BruceRMcF]

okwatts wrote:

As I indicated in the B/BUF thread I have code from one of Bill Shen's (Plasmo) CRC65 boards. I have zipped up the forth asm and listing as well as my modifications for the monitor that applies for my actual read and write routines used by Fig-forth. His board uses a CF card but the sector size is 512 bytes as in the SD card. I used essentially the same code for Grant Searles Multicomp with the SD card. Hope this helps.

One difference I see right away is that they have the assembler compute BMAG.

Also, they are set up to have a raw sector block system on a single 128KB track, so they set up SECTR to force Drive1 to be empty.

Code: Select all

	;; to start with, disk I/O will be to a single
	;; 128 kB on track $C0 but could keep going
SSIZE     = 512			; sector size in bytes
NBUF      = 2 ;4 		; number of buffers desired in RAM
				; (SSIZE*NBUF >= 1024 bytes)
;;; these will limit things to 512*256/1024 128 screens..
SECTR     = 2560		; sector per drive
				; forcing high drive to zero
BMAG      = (SSIZE+4)*NBUF	; total buffer magnitude, in bytes
				; expressed by SSIZE+4*NBUF

Compared to the 1980 fig-Forth listing in the screenshot.

Since all disk access goes through R/W, one quick and dirty way to try to figure what is going on is to write an "overlay" R/W that does a check for the block number being a valid block number, displaying the R/W inputs and aborting if it is not, and then calling the original R/W routine if the block number is OK. Based on whether running gives an abort or a crash would narrow down whether the problem is an invalid block number being handed to R/W or that fig-forth's definition of R/W itself requires a rewrite (eg, code in R/W that is dependent on the sector length being less than 256).

[SamCoVT]

Do post back if you figure out what difference makes it work or not work. I got stuck in the exact same place (trying to get 512 byte sectors working and it would crash when loading screens) and never figured it out. It would be nice to know what the problem was, even if I don't have any plans to go back to Fig Forth.

[powersoft_51]

Yesterday I have tried a lot of combinations as describe in Dr.Ting.
The only value is workings 128 bytes/sector.
All the others are crashed when I give in for example 5 load and I have put in screen 5 only the word : test :

I find it strange that everything can be done with the editor,
edit the text save it, but at the moment that il enter nnn load
it goes wrong, when sector . 128 bytes. I have already investigated the source to see if
there is a hardcoded value in the source but could not find anything.
I find this very strange!
What are the other possibilities?
Also found an apple figforth which for example uses a value
for b/buf of 1024. Who has any experience with this size of
the buffer or two times 512 bytes could also work well for me.

[BruceRMcF]

powersoft_51 wrote:

... I have already investigated the source to see if
there is a hardcoded value in the source but could not find anything. ...

Could you share the source for your R/W primitive function? That's the function that interfaces the BLOCK system to specific storage hardware, so if there is an implicit limit on the length of the buffer in the code somewhere, R/W is where it is most likely located.

If a R/W could be written to support 1024 byte fig-Forth blocks, that's convenient, since later Forth systems often assumed 1024 byte BLOCKs, so it simplifies porting Forth source written for later systems.

[powersoft_51]

This is the code I use, and for testing I use for the virtual memory the free memory that is available.

Code: Select all

;
;
L3400      .BYTE $82,"L",$Cf   ; LO
          .WORD L3732
LO        .WORD DOCON
          .WORD MEM      ; LO ADRESS RAMBUFFER

;
;
L3450      .BYTE $82,"H",$C9   ; HI
          .WORD L3400
HI        .WORD DOCON
          .WORD $6800    ; HI ADRESS RAMBUFFER
;
;                                       R/W
;                              Read or write one sector
;
L3060     .BYTE $83,"R/",$D7
          .WORD L3450    ; link to HI
RSLW      .WORD DOCOL
          .WORD TOR		; SAVE FLAG
          .WORD BBUF
          .WORD STAR
          .WORD LO
          .WORD PLUS
          .WORD DUP
          .WORD HI
          .WORD SWAP
          .WORD ULESS		; LO + BLK * B/BUF > HI
          .WORD LIT,6
          .WORD QERR		; PRINT ERROR 6
          .WORD RFROM		; RESTORE FLAG
L1        .WORD ZBRAN
          .WORD $0004		; L2-L1
          .WORD SWAP
L2	  .WORD BBUF
          .WORD CMOVE		; VERPLAATS BLK
          .WORD SEMIS
;
;

[BruceRMcF]

Ah! If R/W is in high level code using free RAM, then there won't be any page boundary or register width issues. And the only embedded constant in the code is the error message number

Thanks for that, since other people seem to have had the same trouble, it doesn't seem to be a problem with how R/W is coded.

One thing to do is to see whether the BLOCK system is working well with 512 byte sectors independent of the SCREEN system used when interpreting from blocks, which can be done from the command line: Something like write the block number to the base of a block, set it to UPDATE, do that for the first five blocks, then read those blocks and test whether the block number is stored at the base.

If that works, then it points toward the problem being somewhere in the translation of screens to blocks.

Untested, but I expect that would be something like:

: blkset ( blk# -- blk#++ ) DUP DUP BLOCK ! UPDATE 1+ ;
: blktest ( blk# -- blk#++ ) DUP DUP BLOCK @ = . CR 1+ ;
0 blkset blkset blkset blkset blkset CR .
0 blktest blktest blktest blktest blktest CR .

[SamCoVT]

You already have some modifications to your code. I went back to the version of Fig I was using and found this:

Code: Select all

;                                       B/SCR
;                                       SCREEN 35 LINE 10
;                                       Blocks per screen
;
L992:   .byte $85,"B/SC",$D2
        .word L984              ; link to B/BUF
BSCR:   .word DOCON
        .word 8                 ; blocks to make one screen

That might be why my version was crashing, as it was always trying to load 8 blocks per screen, regardless of the block size. Your code looks appropriately modified to handle other block sizes, but you may want to just verify by doing:

Code: Select all

B/SCR .

in Forth to verify you really have 2 blocks per screen.

BruceRMcF's suggestion of testing the block system looks like a good place to start, but it would also be good to know when exactly it gacks. Is it on the first line of screen? In the middle of a screen (which would be when it needs to load in the next block) or at the end of a screen (perhaps not ending properly when it should)? It sounds like you are able to use a screen editor to enter a screen. Can you enter and load something like this:

Code: Select all

." Line 1" CR
." Line 2" CR
." Line 3" CR
." Line 4" CR
." Line 5" CR
." Line 6" CR
." Line 7" CR
." Line 8" CR
." Line 9" CR
." Line 10" CR
." Line 11" CR
." Line 12" CR
." Line 13" CR
." Line 14" CR
." Line 15" CR
." Line 16" CR

to see how far it makes it before it crashes.
[edited to fix typos]

[BruceRMcF]

SamCoVT wrote:

... Can you enter and load something like this:

Code: Select all

." Line 1" CR 
...
." Line 16" CR

Yes, if the BLOCK system seems to be working, then that is a lovely debug screen to test where the SCREEN system messes up, since it's likely to be either before line 1, between lines 8 and 9 (with 512 byte blocks), or after line 16.

And if 128 byte blocks are working, I'd expect the first or the last. If it can transition to 7 additional blocks per screen, it seems like it ought to be able to transition to 1 additional block.

[Dietrich]

I have in my fig-Forth (original version)

Code: Select all

 SSIZE	= 256
NSEC	= 16
NBUF	= 4
BMAG	= SSIZE+4*NBUF

Works as expected since nany years. So there must be an error in your code

Dietrich

[BruceRMcF]

Dietrich wrote:

I have in my fig-Forth (original version)

Code: Select all

 SSIZE	= 256
NSEC	= 16
NBUF	= 4
BMAG	= SSIZE+4*NBUF

Works as expected since nany years. So there must be an error in your code

Dietrich

Is that a left to right arithmetic assembler or Order Of Operations? If Order of Operations, I would think it's (SSIZE+4)*NBUF

[Dietrich]

Yes, it is a left to right assembler. So mathematically it is (SSIZE+4)*NBUF.
Sorry for the ambiguity.
The buffer resides in high memory at $8000 up to high memory
Dietrich

[Dietrich]

Here is the code for my very simple RAM disc for reference

Code: Select all

 L3060	DB $83,'R/',$D7		;R/W 1 SECTOR in RAMdisc
	DW L2924
RSLW	DW DOCOL
	DW TOR,LIT,SSIZE,STAR
	DW LIT,LOWMEM-$C00,PLUS ;SCR #3 is first screen
	DW DUP,LIT,LOWMEM,ULESS	;check LOWMEM and HIMEM
	DW OVER,LIT,HIMEM
	DW GREAT,OR,CLIT
	DB 6
	DW QERR
	DW DUP,EOM,AT		;check EOM
	DW GREAT,ZBRAN
L3063	DW L3064-L3063
	DW DUP,EOM,STORE	;set EOM
L3064	DW RFROM,ZBRAN
L3061	DW L3062-L3061,SWAP
L3062	DW LIT,SSIZE,CMOVE
	DW SEMIS

Dietrich

[powersoft_51]

Thanks all for your replies.
Today have taken a fresh FigForth source, make two modifications.
Replace u< because in the original was a error, and change te R/W routine.
Fig is running in the Kowalski emulator, and runs fine.
But when I do empty-buffers, 5 list the system is hanging, or waiting for input.
I have further make no changes.

Include as zip my source file, and a screen print when list screen 5