Devlog: Vixx (bullet hell game)

VincentF · Post by **VincentF** » Sat Jan 30, 2021 6:58 pm

Thank you for your advice ! I'll try to add some check for the status this evening and see if it works better this way.

Just in case, here's the loading code :

Stefan · Post by **Stefan** » Sat Jan 30, 2021 8:07 pm

OK. Please let us know if it solves your problem. Interesting issue after all.

kliepatsch · Post by **kliepatsch** » Sun Jan 31, 2021 8:30 am

You need to add ",s,r" or so to the file name to communicate to the disk driver that you are opening a sequential file (basically every file that isn't a BASIC or .PRG file IIRC) for reading.

When I tried around with files I had the same issue with blinking LED and couldn't figure out what was happening. The documentation isn't very clear about this.

For more info about this, I suggest reading https://en.m.wikipedia.org/wiki/Commodore_DOS

VincentF · Post by **VincentF** » Sun Jan 31, 2021 9:12 am

30 minutes ago, kliepatsch said:

You need to add ",s,r" or so to the file name to communicate to the disk driver that you are opening a sequential file (basically every file that isn't a BASIC or .PRG file IIRC) for reading.

I know this already ^^ here's the filenames I use (when writing I do a len+2 to include the overwrite element) :

file_hiscore_len = 11

file_hiscore_w !pet "@:bhellsc,s,w"

file_hiscore_r !pet "bhellsc,s,r"

By the way, thank you for the link ?

12 hours ago, Stefan said:

OK. Please let us know if it solves your problem. Interesting issue after all.

Okay so I got some updates on why the sdcard get corrupted. It seems that a software on my computer had locked the file for reading and I suspect that was causing the issue (so this joins the problem when the sdcard is mounted on the local filesystem).

However, this does not prevent the sdcard activity light from blinking continuously only when we attempt to load a non-existing file. I need to investigate this further.

Stefan · Post by **Stefan** » Sun Jan 31, 2021 11:29 am

The blinking pixels at top right corner goes away after you read the disk status.

In assembly, you need to open yet another file for reading with secondary address 15 (=command channel) to do this.

Greg King · Post by **Greg King** » Tue Feb 02, 2021 8:32 am

There are two bugs in your code:

It must call CLRCHN before calling CLOSE.

If the file doesn't exist, then a time-out status bit, not the end-of-file bit, is set.

VincentF · Post by **VincentF** » Tue Feb 02, 2021 12:10 pm

Thanks for the information ? I'll fix all of this asap

3 hours ago, Greg King said:

It must call CLRCHN before calling CLOSE.

I had previously switched CLRCHN and CLOSE but when trying to debug the file corruption + led activity light I noticed it was this way on x16-edit :

3 hours ago, Greg King said:

If the file doesn't exist, then a time-out status bit, not the end-of-file bit, is set.

Strangely, when opening the non existent file, here's what I got after OPEN and after READST :

According to the documentation, READST should set bit 1 of the accumulator (so value = $02) but on my debugger it's just sending $00.

? If you got an idea of what I should look at... I'm checking for an EOF because that was how it was done on x16-edit (link) and it does work as intended.

The only remaining thing is to stop the SD card activity led from blinking.

On 1/31/2021 at 12:29 PM, Stefan said:

In assembly, you need to open yet another file for reading with secondary address 15 (=command channel) to do this.

I quickly tried to do that :

(didn't set the name since it was done earlier)

But the blinking is still here ?

One thing I'll do is create a blank file, it should fix this issue once and for all.

Thank you for helping me figure this out ! ? It's really appreciated !

EDIT: creating the file effectively fixed the blinking issue ^^

Greg King · Post by **Greg King** » Tue Feb 02, 2021 5:24 pm

5 hours ago, VincentF said:

The only remaining thing is to stop the SD card activity led from blinking.

I quickly tried to do that :

(didn't set the name since it was done earlier)

But the blinking is still here ?

To what was the name set earlier? You must call SETNAM with the accumulator set to zero (the other two registers don't matter when the "name" has zero length)! Otherwise, the "name" string is sent as a DOS command (which might cause a syntax error). Also, you actually must read the status message, in order to cancel the error.

VincentF · Post by **VincentF** » Tue Feb 02, 2021 5:56 pm

31 minutes ago, Greg King said:

To what was the name set earlier?

The file is "bhellsc,s,r", and I called SETNAM with the accumulator set at value #11 (the length of the string)

Reading the documentation, I think I understand why I need to call with accumulator set at #0, that's because we don't want any file.

I find the OPEN command (and others file management commands) quite obscure because wherever I try to search information for it there is always some missing info. (for example secondary addresses)

Stefan · Post by **Stefan** » Tue Feb 02, 2021 6:21 pm

Hi,

The read loop in my program stops if READST returns anything else than 0.

I have tested what return value you get from READST on file not found. And it is $42. That is $2 (time out read) + $40 (end of identity, sort of end of file). As your code tests for $40 that doesn't seem to explain your problem.

To read the disk status, you need to open the command channel with a zero length file name. Otherwise you are effectively sending the file name to the drive which will try to interpret it as a DOS command. In most cases this will cause a syntax error, and the blinking continues.

To see what I mean, try entering DOS "<anyfilename>" at the BASIC prompt. The blinking light turns on. Then read the status by entering just "DOS". You can see that the last error was syntax error.

I haven't tested it, but you might actually also need to read the byte stream from the command channel before closing it in order to make the blinking light go away. Only by reading the stream, you get to know what disk error occurred, if that's of any interest to you.

Finally, Greg and I discussed the order in which you should call CLOSE and CLRCHN some time ago. It's common to find C64 code examples online that first calls CLOSE and then CLRCHN. When testing this thourougly, I found that it doesn't matter in which order you call these functions. Having used X16 Edit for several months now, I have not had any file related problems with calling CLOSE first and CLRCHN second. I think you may rule out that this has anything to do with your problem.