NuLA demos

[simonm]

I'm afraid I haven't had time to look at this yet, and I'm not familiar with the problem device so if anyone else can offer a fix I'm happy to accept a pull request. The source is all on the GitHub.

[sydney]

I might have a little spare time this morning so will have a look and see how much work it'll be to work with smartspi and other sdcard systems.

[sydney]

Ok. I've been looking at the code and the program seems to freeze at the following point (though I could well be wrong!):

Code: Select all

	
ldx #LO(file_name)
ldy #HI(file_name)
lda #&40    ; a=&40 = open file for read
jsr &ffce   ; osfind
bne file_exists

Does anyone know if osfind is supported on mmc systems generally and smartspi specifically?

[sydney]

Hmm. Seems I'd already tested whether osfind worked and it does:

Code: Select all

INCLUDE "macros.asm"
INCLUDE	"acornconstants.asm"

ORG $2000
.start
	MODE 7
	
	;find file
	ldx #LO(file_name)
	ldy #HI(file_name)
	lda #&40    ; a=&40 = open file for read
	jsr &ffce   ; osfind
	bne file_exists
	lda #7
	jsr oswrch
	rts

.file_exists

	;close it
	tay         ; y=file handle
	lda #0      ; a=0 = close file
	jsr &ffce   ; osfind
    
	ldx #LO(oscli_string)
	ldy #HI(oscli_string)
	jsr oscli
	rts		;end of program

.file_name
	equs "TEST"
	equb 13

.oscli_string
	equs "LOAD "
.oscli_filename
	equs "TEST"
	equb 13
	
.end
SAVE "MAIN",start,end
PUTFILE "TEST.TXT", "TEST", &7D00 

My head is hurting now so off to get the kids and have a strong cup of tea.

[sydney]

I'm a bit stumped. I've stripped the code posted on github by Simon down to what I think is the bare minimum and what I'm left with works on beebem using the standard Acorn DFS but not with smartspi.
I've narrowed it down to this piece of code:

Code: Select all

.load_file
	; check if the next file exists
	ldx #LO(file_name)
	ldy #HI(file_name)
	lda #&40    ; a=&40 = open file for read
	jsr &ffce   ; osfind
	bne file_exists
	
	;beep - demonstates infinte loop
	lda #7
	jsr oswrch

	
	; reset sequence if not - sets file name back to A.01 which worked 1st time round
	lda #'0'
	sta file_num+0
	lda #'1'
	sta file_num+1
	jmp load_file
.file_exists

The first call to load_file has file_name set to "A.01" and loads the file no problem. file_name is changed to "A.02" by the following code and osfind can't find it on subsequent calls to load_file using smartspi but can using DFS. When osfind can't find the file, file_name is changed back to "A.01" but still can't be found in smartspi but can in DFS.

Code: Select all

		; advance to next file in sequence
		inc file_num+1
		lda file_num+1
		cmp #48+10
		bne continue
			lda #48
			sta file_num+1
			inc file_num+0
    
		.continue

This leads me to believe osfind doesn't work in smartspi. Any thoughts?

I've attached a zip of my stripped down project.

[RobC]

Thanks for putting so much effort into looking at this.

Might the SPI OSFIND be overwriting the filename block? What happens if the filename is completely reset to "A.01" rather than just resetting the "01" bit?

[sydney]

Thanks for putting so much effort into looking at this.

Might the SPI OSFIND be overwriting the filename block? What happens if the filename is completely reset to "A.01" rather than just resetting the "01" bit?

The data is stored like this at the end of the program:

Code: Select all

.file_name  EQUS "A."
.file_num   EQUS "01", 13

So I think the whole filename is reset by changing only the file_num part. Might give it a try though.

EDIT: Just spotted an error! Don't think it'll matter though.

[simonm]

Interesting findings sydney, thanks for looking into this.
I'm willing to admit that my code tends to be fairly gung ho on memory usage as I'm usually writing demo code that nukes all pockets of memory for my own nefarious single purpose single platform uses, so its possible I'm trampling some workspace memory this other filing system is using.

This particular version of disksys.asm plays nicely with memory though, as I sanitized it somewhat after it was used in the last demo we did.

The code is ORG'ed at &1400, perhaps bumping that to &1800 would help? (&1900 breaks the guard limit).
The decompressor eats &400-&800, but that should be ok as usually just BASIC workspace.

The ZP is ORG'ed at &00, since again it doesn't need any OS language stuff. Maybe thats a problem?

Finally the SWR loading is pretty fruity. It loads sectors at a time into main ram buffer, then switches in the SWR bank to copy them over. Possibly some scope for issues here, but since the DFS ROM seems ok I dont see why an alternative FS ROM wouldnt work too.

Worst case scenario is that I've put some nasty memory glitch/overrun bug in there that is benign on DFS systems but deadly on others...

Hmm....

[sydney]

The error I found was that I was loading the file twice - once using osfile and once using oscli load a.01.
Both work and fail in the same way! Made no difference to the main problem.
My initial thought when starting this was that osfile was the problem, which was why I moved to oscli, but I'm no nearer finding that out due to the problems with osfind.

[sydney]

Interesting findings sydney, thanks for looking into this...

Simon, the code I've posted is almost unrecogisable as the code you posted. I've stripped out all of the SWR, shadow and disksys code. It really is the bare bones so I'm pretty sure the fault lies in the filing system implementation - or lack of - osfile, osfind etc
Cheers.

[simonm]

sure, good idea.
I see the source code for the SmartSPI ROM is on hoglets GitHub repo - maybe we can sniff out what the implementation of osfile looks like? I'm not especially skilled at this sort of code though.

[simonm]

Now that we seem to have the theory that its OSFILE/OSFIND thats causing the issue, I'm currently putting in a workaround for this so we can see if that fixes it.

[simonm]

Can someone with the problem FS please try the attached SSD and see if behaves itself? It's a hacky version so doesnt look pretty but will at least indicate if we're on the right lines here... thx

If it fixes the issue, I'll tidy up the code and release patched SSDs

[sydney]

Hi Simon.
Just a quick test on beebem and the nula logo is displayed then after the delay I get:

Code: Select all

File not found 

Bad program

Not able to test on real hardware until Thursday afternoon.

[simonm]

Blerg! What fresh hell is that then I wonder??! Works ok for me in BeebEm...
Thanks for checking tho.

[sydney]

I'm running the windows version of beebem under wine on linux so this may be causing a problem. I have windows 10 on another laptop but don't use it much so I'll need to install beebem on that to eliminate linux as the problem - I'll probably find it easier to test on real hardware! Again it won't be until Thursday afternoon when I get a chance to have a look at it.

[hoglet]

sure, good idea.
I see the source code for the SmartSPI ROM is on hoglets GitHub repo - maybe we can sniff out what the implementation of osfile looks like? I'm not especially skilled at this sort of code though.

Really???? where exactly?

Do you actually need any NuLA hardware (or software) present to see this issue?

If not, I can take a quick look at this with ICE-T65.

Dave

[sydney]

Do you actually need any NuLA hardware (or software) present to see this issue?

If not, I can take a quick look at this with ICE-T65.

Dave

Since the problem is purely with disc access then NuLA hardware isn't needed.
I've not tested with mmfs, only smartspi and beebem under wine on Linux doesn't seem to work with mmfs so the problem could be with smartspi only.
The initial build failed on my beeb with smartspi and nula in what looks like the same way as beebem with smartspi.

[simonm]

Really???? where exactly?

My bad, thought these were the same things. I'm a n00b on this stuff.

[hoglet]

The initial build failed on my beeb with smartspi and nula in what looks like the same way as beebem with smartspi.

For consistency, which version of SmartSPI are you using?

Dave

[simonm]

For what its worth, and in case it's helpful, here is the code as it was:

Code: Select all

Use OSFIND to open a file for read. 
If it succeeds:
     close the file
     proceed to load it using OSFILE (mainly so that we can get the file's load + exec address into a param block).
otherwise:
     reset filename for the numbered file sequence back to the beginning (implying we've reached the last file in the sequence)

The code is now:

Code: Select all

Fetch the disk catalog from the first two sectors of the disk to a 512 byte memory buffer using the DFS
Scan the catalog buffer for the required filename
if it is found:
    *LOAD the file
    Parse the file load+exec address attributes from the buffered disk catalogue 
 otherwise:
    reset as above

Filenames are named A.NN where NN ranges from 01 to 27

[hoglet]

I've debugged this in a real Beeb with SmartSPI 1613 using the new ICE-T65 (the one built using the cheap eBay LX9 board):

The problem is indeed that OSFIND fails (for me it was with a MMC Read Fault FF/000000).

It turns out the cause is a conflict over the use of memory in page &Dxx, which SmartSPI uses as it's workspace

Specifically, SmartSPI uses location &D4F to store the card type (e.g. SD or SDHC). If this gets corrupted, the low level SD access code will fail.

Page &Dxx is used in the Nula Demo by the EXOMISER compression library:

Code: Select all

\\ ******************************************************************
\\ EXOMISER (compression library)
\\ ******************************************************************

\\ Uses memory:
\\ &0400-0800	- 1024 byte decompression buffer
\\ &0D02-0D9F	-  156 byte decompression table
\\ Plus ZP vars
\\ Exomiser decruncher routine installs empty NMI handler at &0d00

\\ Compress data using:
\\ exomizer.exe raw -c -m 1024 <file.raw> -o <file.exo>

(also illegally as it turns out, though there is a comment in the code that *FX 143,12 should be called to claim NMI workspace).

MMFS does seem to work correctly as it doesn't use page &Dxx for workspace.

Dave

[sydney]

Cheers Dave.
Looks like I'll be using MMFS on my beeb from now on then as I don't want to attempt removing the video ula from my master.

[RobC]

Looks like I'll be using MMFS on my beeb from now on then as I don't want to attempt removing the video ula from my master.

Just to be clear, the incompatibility isn't with the VideoNuLA board but with the demo

[sydney]

Looks like I'll be using MMFS on my beeb from now on then as I don't want to attempt removing the video ula from my master.

Just to be clear, the incompatibility isn't with the VideoNuLA board but with the demo

Yes. The demo uses compression to fit more pictures on the disk as a 200k disk / 20k screen = max of 10 image. The exomiser decompression code is using the same workspace as the smartspi filing system and so the sd card simply stops working after the first image has been decompressed. No problems at all with VideoNuLA.

[sbadger]

Cheers Dave.
Looks like I'll be using MMFS on my beeb from now on then as I don't want to attempt removing the video ula from my master.

it's like shaving yaks getting this working, I just tried to load MMFS into swram and *unplugged my smartspi rom, it just gives me 'Card?'

[simonm]

Aha, outstanding sleuthing chaps, thanks.
This probably means almost all of our demos wont work on this FS then, since we've been playing fast and loose with page 13, like forever!

I've relocated this buffer and attached a patched SSD (this one has the old OSFILE/OSFIND code back in). Please could some kind person see if that solves the problem?

[simonm]

Cheers Dave.
Looks like I'll be using MMFS on my beeb from now on then as I don't want to attempt removing the video ula from my master.

it's like shaving yaks getting this working, I just tried to load MMFS into swram and *unplugged my smartspi rom, it just gives me 'Card?'

Hmmm... on the assumption your issue is related to this demo, I can disclose that the demo will use any old SWR bank it finds and if the incumbent FS happens to be loaded there it will be nuked. Us demo hackers do not consider these scenarios. Righto, that's the next compatibility job for me then.

[hoglet]

it's like shaving yaks getting this working, I just tried to load MMFS into swram and *unplugged my smartspi rom, it just gives me 'Card?'

Most likely you have loaded the wrong build of MMFS for your system.

Which file did you load?

What model of BBC are you using?

Dave

[sbadger]

Aha, outstanding sleuthing chaps, thanks.
This probably means almost all of our demos wont work on this FS then, since we've been playing fast and loose with page 13, like forever!

I've relocated this buffer and attached a patched SSD (this one has the old OSFILE/OSFIND code back in). Please could some kind person see if that solves the problem?

hmmmmmmmmm. still seems to hang at the Nula screen